: We index using 4 processes that read from a queue of documents. Each process : send one document at a time to the /update handler.
Hmmm.. then you should have a message from the LogUpdateProcessorFactory for every individual "add" command that was recieved ... did you crunch those to see if anything odd popped up (ie: duplicated IDs) what did the "start commit" log messages look like? (FWIW: I have no hunches as to what caused that behavior, i'm just scrounging for more data) : Yes, I double checked that no delete occur. Since that indexation, I : re-index the same set of documents twice and we always end up with 7725 : documents, but it did not show that ~10000 documents count that we saw the : first time. But the difference between the first indexation and the others : was that the first time, the indexation last a couple of hours because the : documents were not always accessible in our document queue. The others Hmmm... what exactly does yout indexing code do when the documents aren't available? ... and what happens if you forcibly commit in the middle of reindexing (to see some of those counts again) : About the newSearcher warming query, it is a typo in the config. It should : have been 'qt'. Thanks for this one! Even if you change wt to qt that won't make the query make sense (q=*:* isn't a very useful query string when using qt=dismax) -Hoss
