少し前にエントリーした件ですが、解決というか結果からすると回避する事が出来ました。
まず、ログを調べようと考え、config/logging.yml上でログをデバッグ出力に変更。
#es.logger.level: INFO
es.logger.level: DEBUG
実際に取込んでみたところ、出力されるログには
[2014-04-25 09:58:00,343][INFO ][org.xbib.elasticsearch.river.jdbc.strategy.simple.SimpleRiverMouth] bulk [225] success [100 items] [20ms]
[2014-04-25 09:58:00,358][INFO ][org.xbib.elasticsearch.river.jdbc.strategy.simple.SimpleRiverMouth] bulk [226] success [100 items] [15ms]
[2014-04-25 09:58:00,362][INFO ][org.xbib.elasticsearch.river.jdbc.strategy.simple.SimpleRiverMouth] new bulk [227] of [100 items], 1 outstanding bulk requests
[2014-04-25 09:58:00,373][DEBUG][org.xbib.elasticsearch.river.jdbc.strategy.simple.SimpleRiverSource] merged 22709 rows
[2014-04-25 09:58:00,378][INFO ][org.xbib.elasticsearch.river.jdbc.strategy.simple.SimpleRiverMouth] bulk [227] success [100 items] [16ms]
[2014-04-25 09:58:00,382][DEBUG][org.xbib.elasticsearch.river.jdbc.strategy.simple.SimpleRiverFlow] … fetched, flushing
見たいに書かれて、22709件実施したと出る。
ただし、実際にElasticsearch側へ登録されたデータ件数はもっと少ない状態でした。
river側は処理したが、データ不正かなにかによってElasticsearch側ではじかれたのか？
それともまさかUpdateされた？と思って地道に失敗したレコードの一部を特定。
単独でjdbc-riverを実施してみると・・・
問題なく登録される。
以前話に聞いた、大量件数を実施した時に問題が起こるって奴なのか？と再び考え、
たかだか２万件程度で問題が無いと思いつつも/config/elasticsearch.ymlに下記の設定を追加
ちなみに、参考にさせていただいたのはこちら
threadpool.index.queue_size: -1
threadpool.bulk.queue_size: -1
参考サイトには、キューが足りなくなったときと書いてあった。デフォルトでは30。
ログを見る限り、多分「outstanding」で示された数がそれに当たるんだろうけど、
それらは30に達しているようには見えない。
最高でも17〜18程度に見える。
そう考えると、これの影響は内容に思えるのだが、なぜかこれを設定する事で件数はあった。
ちょうど、jdbc-riverを見てたら話題になっていた
It is an issue with BulkProcessor class of ES. I patched the class and will release a fixed version of JDBC river soon.
https://github.com/jprante/elasticsearch-river-jdbc/issues/228こちらはriver側のパラメータ指定で回避されたと報告されている。
受け渡す側のしきい値か、受け取る側のしきい値かの違いだとは思う。
どのしきい値に達したのかは、数からしてちょっと納得いかないものがあるがログくらいには出して欲しいものだ。
さしあたってなんとかなったけど、この辺りはもう少しなんとかしたいところだと思うので
今度ソースを当たってみよう。
KADOKAWA/アスキー・メディアワークス
売り上げランキング: 77,882