[groonga-dev,03141] Re: selectの出力のJSONが壊れていることがある

Back to archive index

Kouhei Sutou kou****@clear*****
2015年 3月 31日 (火) 14:08:30 JST


須藤です。

In <55194****@doga*****>
  "[groonga-dev,03140] selectの出力のJSONが壊れていることがある" on Mon, 30 Mar 2015 21:27:51 +0900,
  Masumi SHOJI <shoji****@doga*****> wrote:

> 妙な現象に遭遇しましたのでご報告いたします。

ありがとうございます!
こういうごくまれに発生する現象はそもそも発見することが難しい
ので報告してくれることはとても助かります!

> groongaのselectが返すJSONが壊れるという現象がごくまれにですが
> 発生しています。
> 具体的には以下の様にBODYの直前に余分な"1"が付きます。
> 
> [[0,1426775540.63765,0.00017857551574707],1[[[2],[["_id","UInt32"],["_key","UInt64"],
>> 
> "1"は1個とは限らず、"1111"と4個連なっていることもありました。

たしかに妙ですね。
この余分な値なんですが、"1"以外の値(たとえば"2"とか)になる
こともありますか?必ず"1"ですか?

また、余分な値が入る場所はいつもその場所ですか?

Groongaの内部では、先頭の

  [[0,1426775540.63765,0.00017857551574707],

の部分(HEADERのあとの「,」まで)と

  [[[2],[["_id","UInt32"],["_key","UInt64"],...

のBODY部分で別のバッファーを使っています。なので、余分な値が
入る場所としては「入りそうかも」という場所です。

ここに入っているということは「先頭の部分」用のバッファーの最
後か「BODYの部分」用のバッファーの最初に入っている可能性が高
いです。

が、ソースコードを確認しただけでは怪しそうな場所を見つけられ
ませんでした。。。

> 再現条件は申し訳ありませんが特定できていません。
> 現象は、DBの状態や検索条件が全く変わらなければ再現するのですが、
> 以下の様に出力に影響しなさそうな条件が変わっただけでも発生しなく
> なってしまい、またごくまれにしか発生しないので、意図的に発生させる
> 条件が見つけられていません。
> 
> ・ヒット件数より大きなlimit値を設定している場合でもlimit値を変えると
> 発生しなくなる。
> (例: ヒット件数2件に対しlimitが12ならば発生し10ならば発生しないなど)
> 
> ・検索条件にヒットしないレコードが追加されても、全く同じ検索条件で
> 発生しなくなる。

たぶん、これはキャッシュのせいだと思います。
Groongaは内部でキャシュをしているので、同じクエリーなら実際
には検索処理をせずにキャッシュしてあった結果を返します。

limit値を変えて再現しなくなるのはキャッシュの値(余分な"1"が
入っている)を使ったのではなく、実際に検索してその結果を返し
ているからだと思います。

また、キャッシュはレコードを追加するとクリアーするので、レコー
ドを追加した後は、同じ検索条件でも新しく検索しなおします。

> Groongaは-dオプションでHTTPサーバとして動かしていて、
> 現象はwebブラウザからのアクセスで確認しました。
> 
> DBは、公式のチュートリアルの「4.10. マイクロブログ検索システムの作成」を
> 参考に、テキスト本体、語彙表、ハッシュタグの3つのテーブルで構成しています。
> プロジェクト名をテーブル名に含んでいたりしますので、
> テーブル生成の一連のコマンドをそのまま転記するのは避けさせてください。
> 
> テキスト本体のテーブルは以下のカラムを持ちます。
> UInt64の_key、ハッシュタグのベクターカラム、検索対象のLongText、
> Time型のデータ生成日時と更新日時、UInt8のフラグ、UInt64のユーザID
>
> ハッシュタグと語彙表のテーブルは、4.10の例に倣って作成しました。
> ただ、語彙表はcomment_indexに相当するものだけで、
> デフォルトトークナイザーには当初はTokenMecabを使用していて、
> 途中でTokenBigramSplitSymbolAlphaDigitに変更して作り直しましたが、
> その両方で発生しています。
>
> なお、DBには、同じマシンで稼働する別のシステムが使用するテーブルも
> 混在しています。(関係無いかもしれませんが)

情報ありがとうございます。
助かります。

変わった使い方でもないですし、問題になりそうなものはなさそう
に感じました。

> 環境は以下の通りです。
> 
> OS: CentOS6.6 64ビット
> Groonga:
>   以前はバージョン4.0.4をソースからビルド
>   現在は5.0.0のパッケージをyumでインストール
>   その両方で発生しています。

とすると、結構前からの問題なんですね。。。

もし可能だったらなんですが、4.0.2も試してもらうことはできま
すか?4.0.3でバッファーの構造を少し変えたのです。もしかした
らそれが原因なのかも?と思いまして。。。


-- 
須藤 功平 <kou****@clear*****>
株式会社クリアコード <http://www.clear-code.com/>

Groongaベースの全文検索システムを総合サポート:
  http://groonga.org/ja/support/
パッチ採用 - プログラミングが楽しい人向けの採用プロセス:
  http://www.clear-code.com/recruitment/
コードリーダー育成支援 - 自然とリーダブルコードを書くチームへ:
  http://www.clear-code.com/services/code-reader/




groonga-dev メーリングリストの案内
Back to archive index