Hi, On Wed, 2008-02-06 at 16:36 +0100, Roland Weber wrote: > Hm, I didn't get the last part about not reaching the wait. You have > more than 300 threads and just 128 connections, so I don't see a > problem with 200 threads waiting at the same time if the machine > is busy. Then I wasn't clear enough (sorry for my bad english :)), we do not have 200 but 300 threads waiting at the same time... The threaddump (http://senduit.com/93f7d2) shows 302 waiting threads and 6 that are running.
I count 302 by doing this: grep "doGetConnection(MultiThreadedHttpConnectionManager.java:518)" threaddump.txt | wc -l These threads have "CommonsHttpSolrServer.java:222" in the stack. I count 6 with this: grep CommonsHttpSolrServer threaddump.txt | grep -v CommonsHttpSolrServer.java:222 | wc -l Is anything wrong with this? Asuming that not, we do not have 128 checked out connections but only 6. The effect is also, that these 302 thread are blocking "forever" and we have to restart the server, as no new requests are being served... > I'm not saying that MTHCM is bug-free, but let us first consider > if it is operating correctly. Hopefully - I would prefer that it's simply a wrong usage of httpclient :) > Is it possible that you have several > hundred threads trying to access the same target host? Yes, I would say. All the requests access a loadbalancer that fronts two search servers. > These would end up waiting on the same pool, and only 32 connections are given > out for each pool. 6 threads not blocked, 26 blocked on reading or > writing, and the rest waiting for a connection to be released? Ok, so we should have 32 instead of 6 running solrj clients. Thanx a lot for your help, cheers, Martin
signature.asc
Description: This is a digitally signed message part
