David, if it's fast for you to reproduce, would it be possible for you
to try the latest Jetty 6.1.24 and see if the issue still exists?
http://dist.codehaus.org/jetty/

Seems like we should upgrade to 6.1.24 anyway (there were quite a few
fixes in 6.1.23)
http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11160&version=16044

-Yonik
http://www.lucidimagination.com

On Thu, May 27, 2010 at 5:43 PM, Smiley, David W. <dsmi...@mitre.org> wrote:
> I'd like to warn people about the default configuration of Jetty in the Solr 
> trunk release (not present in Solr 1.4 and prior).  There is a difference in 
> the jetty configuration which is for the latest Solr to use the 
> QueuedThreadPool (as seen in jetty.xml).  Previously, it had used a 
> BoundedThreadPool implementation that I've heard is considered deprecated 
> presently.  I have a multi-core setup where Jetty is serving up lots of Solr 
> cores 9+ and when our client does a distributed search (3 of them at a time 
> actually), it triggers a condition in which the query takes 50 plus seconds 
> to respond.  During this time, the machine is effectively idle, seemingly 
> waiting for something.  To fix this, go back to the former BoundedThreadPool 
> implementation or don't use Jetty.  FWIW this has triggered us to swtich to 
> Tomcat.
>
> Sorry but I have sunk so much resources into tracking down this nasty problem 
> that I can't spend much more on further figuring out why QueuedThreadPool is 
> failing us.
>
> ~ David Smiley
> Author: http://www.packtpub.com/solr-1-4-enterprise-search-server/
>
>
>
>
>

Reply via email to