Thanks for the answers, I also found that blog post about such issues: http://techbytes.anuragkapur.com/2014/08/potential-jetty-concurrency-bug-seen-in.html
On 01/07/15 20:26, Chris Hostetter wrote:
: Hmm, interesting. That particular bug was fixed by upgrading to Jetty : 4.1.7 in https://issues.apache.org/jira/browse/SOLR-4031 1st) Typo - Shalin ment 8.1.7 above. 2nd) If you note the details of both issues, no root cause was ever identified as being "fixed" -- all that hapened was that Per tried upgrading to 8.1.7 and found he could no longer reproduce with his particular test cases. That doesn't mean the bug went away in 8.1.7, it means something changed in 8.1.7 that cause the bug to no longer surface in the same way for the same person. It's very possible this is in fact hte same bug, but some other minor change in 8.1.7 just changed the input needed to trigger the bug (eg: maybe a buffer size increase/decrease, or a change in the default size of a HashMap, ... anything like that that could tweak the neccessary input size / request count / etc... neccessary to trigger the bug) : > 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. can you reproduce this against a controlled set of data/configs/queries that you can bundle up in a zip file and make available to other people for testing? (ie: non proprietary/confidential configs + data + queries, preferably with a data set small enough that it can be downloaded quickly, ideally under 10MB so it can be attached to jira) -Hoss http://www.lucidworks.com/
