HAYASHI Kentaro
hayas****@clear*****
2015年 4月 8日 (水) 19:23:50 JST
林です。 On Tue, 07 Apr 2015 23:07:13 +0900 Masumi SHOJI <shoji****@doga*****> wrote: > 正司です。 > > スクリプトでループを回して、1000本ノック何セットな勢いで試してるの > ですが、1日1回現象が発生するかどうかというところです。 > ＃これでは4.0.2を投入しても、起きるかどうかの判断はなかなかしにくそう。 > > 一昨日は、cache=noを付けずに全く同じパラメータで1000回実行したら、 > 4回目でだけ "1" が付いたのが返ってきていました。 > > 昨日は、5回毎にパラメータを変えて1000回実行したら、2回目でだけ > "245" が付いたのが返ってきました。 > > というわけで、必ずしも1度発生したらずっと発生し続けるというもの > でもないようです。 > たまたまそのタイミングでDBが更新されたという可能性も無きにしも > 非ずですが。 おぉ。。。相当レアなんですね。 手元で2hくらいループをぶんまわしてみたりして再現しないかなーと思っていたのですが そうそう簡単でもないようで。。。 > >>> cache=noのときでも発生するかどうか確認してもらうことってできますか？ > >>> cache=noで発生しないなら、やっぱりキャッシュのせいだったねということで > >>> もうすこし調べるべき範囲を限定できないかなと思っています。 > > 今日たまたまブラウザで見ているときに "1" が付く現象に遭遇したので、 > URLの末尾に "&cache=no" を付けてみましたが、変わらずでした。 > パラメータの順番って決まってたりします…? いえ、順番は決まっていないので末尾に付与というので問題ないです。 ただ、cache=noつけてもJSONが壊れたままというのは不思議ですねぇ。 > サンプル数が少ないので偶然かもしれませんが、１つ気付いたことが。 > "1" 以外のものが付くパターンで、付く文字列が、取得される先頭の > レコードの _id の近隣の値のようなのです。 > "234" が付いてきたときのレコードの _id は 231 でした。 > "245" が付いてきたときの先頭のレコードの _id は 243 でした。 なるほど、また再現したときにもそうなっていたらとても怪しそうですね。 ちなみに、現象に遭遇したときに投げていたクエリを教えてもらうことってできますか? curl http://localhost:10041/d/select?table=Blogs&match_columns=description&query= みたいなやつです。 そのままだとまずいところは伏せてもらってかまいません。 投げているクエリも近いもので試したいなぁと思っています。 -- HAYASHI Kentaro <hayas****@clear*****>
