On 28 October 2011 06:06, Shay Banon kimchy@gmail.com wrote:
Heya, quickly looked at the code, and I see the problem. The consumeBatches
should feed the next search request with the previous search request scroll
id. It seems like you use the initial scroll id returned from the first scan
request. Things will still work when you don't do it, but you will see the
mentioned failures (and its better to fix it).
Um, ok, that's odd. I had thought the pattern was:
- Initiate a _scan
- get the scrollId from the scan
- call prepareSearchScroll with this scrollId
- continue to use prepareSearchScroll to iterate over the batches passing in
the original scrollId?
Am I reading you right in saying that the first scrollId (scan) is only used
on the first prepareSearchScroll call, and then we're expected to get a
new scrollId from the 1st iteration to use for all the other batches?
Paul