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

Back to archive index

HAYASHI Kentaro hayas****@clear*****
2015年 4月 1日 (水) 13:14:25 JST


林です。

On Tue, 31 Mar 2015 17:55:59 +0900
Masumi SHOJI <shoji****@doga*****> wrote:

> 正司です。
> 
> > この余分な値なんですが、"1"以外の値(たとえば"2"とか)になる
> > こともありますか?必ず"1"ですか?
> > 
> > また、余分な値が入る場所はいつもその場所ですか?
> 
> 今まで目にしたのは全部 "1" で、場所もそこです。
> といっても、それ以外にJSONを壊さないような場所に余分な文字が
> 入って出力がおかしいことがあるかどうかまでは分かりませんが、
> 少なくともデコードできないJSONが返るケースは全部その場所です。

まだ再現させることができていないのですが、
必ず"1"で場所も限定されているというのがわかっただけでも貴重な情報です。
ありがとうございます!

> > limit値を変えて再現しなくなるのはキャッシュの値(余分な"1"が
> > 入っている)を使ったのではなく、実際に検索してその結果を返し
> > ているからだと思います。
> 
> なるほど、ということは、入力パラメータ依存の現象ではなくて、
> パラメータをちょっとずつ変えて繰り返し検索すれば、
> そのうち発生する可能性もあるわけですね。

そうですね。
キャッシュが原因かどうかはクエリにcache=noをつけて無効にしたものと
有効にしたもので再現状況に違いがあるかどうかをみるとよさそうです。

  http://groonga.org/ja/docs/reference/commands/select.html#cache

cache=noのときでも発生するかどうか確認してもらうことってできますか?
cache=noで発生しないなら、やっぱりキャッシュのせいだったねということで
もうすこし調べるべき範囲を限定できないかなと思っています。

> > もし可能だったらなんですが、4.0.2も試してもらうことはできま
> > すか?4.0.3でバッファーの構造を少し変えたのです。もしかした
> > らそれが原因なのかも?と思いまして。。。
> 
> 試してみたくはあるのですが、Groongaを使っている今開発中の
> システムがloadをPOSTで行っているので、すぐには入れ替えられなさそうです。
> (POST対応は4.0.3からですよね)

POST対応はおっしゃるとおり4.0.3からです。なので4.0.2で試してもらうのは
難しそうですね。なので↑のcache=noの結果を試して教えてもらえると嬉しいです。

-- 
HAYASHI Kentaro <hayas****@clear*****>




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