Hello Martin, > Now I wonder, why so many threads are waiting in doGetConnection. They > should be interrupted when MTHCM.notifyWaitingThread is invoked, so it > seems as if this is not called.
It is called only if a connection is returned and given to the specific pool on which a thread is waiting. > Though, this should be the case, asuming that there are/were connections > in use that should be released by solrj otherwise no thread should reach > the wait. 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. > One thread dump containing 302 MTHCM.doGetConnection in state waiting > has 6 threads where the solrj client is processing the response, and > these are not blocking or anything. 6 threads not blocking at all? How many are blocked on reading from or writing to a connection? If there are 122, you know what the problem is. > - DefaultMaxConnectionsPerHost is set to 32 > - MaxTotalConnections is set to 128 > - ConnectionManagerTimeout is not set / 0 > > Has someone an idea what might be wrong here I'm not saying that MTHCM is bug-free, but let us first consider if it is operating correctly. Is it possible that you have several hundred threads trying to access the same target host? 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? In your thread dump, can you please check on how many different connection pools the 300+ threads are waiting? cheers, Roland --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
