Hi,
I have good news (for me :), I have resolved my bug.
As always it was my own fault.
I did a few tests sometime ago so as to understand how instances of
various objects were instanciated in Lucene/Solr, and made a mistake in
understanding how SearchComponent were managed.
I believed that each time a request was to be handled by a
SearchComponent, a new instance of that SearchComponent was
instanciated. So I did not bother about making my SearchComponent thread
safe... I should have.
Thank You for your help,
Kevin
On 01/07/15 11:26, Kevin Perros wrote:
Hello,
I'm new to the solr mailing list, and I have not used solr for much
time, so I might be wrong.
I may have found a bug whose symptoms look that one in jetty
https://bugs.eclipse.org/bugs/show_bug.cgi?id=392936
I am using solr 5.0.0 (the one with the great packaging and deployment
work :). I use a lucene index to store adio fingerprints for audio
tracks, with a custom search system, which reads directly from leaf
readers.
When I query solr with either curl or wget, with multiple parallel
requests from the same client host to the server, the answers come
mixed up. From my logs, I've seen that if I send 10000 requests, with
a 24 fold parallelism, I often get as an answer to a request, the
answer to the first one.
Hence, I have tried to bypass jetty and launch the same batch work
from "inside solr", by writing a dummy request that simulates the
10000 requests, with the same 24 fold parallelism. In that case,
everything works well.
I had already noticed that bug in mozilla. I have a bookmark folder
with a bunch of test requests, and when I click on the "open all in
tabs" button, the result from requests appears in the tab for another
one, in a random fashion.
Regards,
Kevin
