[
https://issues.apache.org/jira/browse/SOLR-683?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12622764#action_12622764
]
Lars Kotthoff commented on SOLR-683:
------------------------------------
bq. Not sure if this is still the case, but I believe Jetty did just use the
standard socket backlog queue
A quick look at the code suggests that this is still the case (at least for
version 6.1.3 bundled with Solr).
bq. When jetty runs out of handler threads, does it not accept new connections,
or does it accept the connection and wait for a thread to become free to handle
it?
When it runs out of handler threads it can't accept the connection because
there's no thread to handle it. The code where this is implemented looks like
this.
{code:title=AbstractConnector.java}
Thread current = Thread.currentThread();
synchronized(AbstractConnector.this)
{
if (_acceptorThread==null)
return;
_acceptorThread[_acceptor]=current;
}
...
while (isRunning())
{
try
{
accept(_acceptor);
}
}
{code}
The connection is only accepted if there's a thread to handle it.
It's clearer in the Tomcat documentation for equivalent parameter (acceptCount
in http://tomcat.apache.org/tomcat-6.0-doc/config/http.html).
> Distributed Search / Shards Deadlock
> ------------------------------------
>
> Key: SOLR-683
> URL: https://issues.apache.org/jira/browse/SOLR-683
> Project: Solr
> Issue Type: Bug
> Components: search
> Affects Versions: 1.3
> Environment: Linux
> jre1.6.0_05
> 8GB RAM
> 2 x 2 core AMD 2.4 Ghz
> 2 x 140GB disk
> Reporter: Cameron
> Assignee: Yonik Seeley
> Fix For: 1.3
>
> Attachments: locked.log, SOLR-683.patch
>
>
> Per this discussion:
> http://www.nabble.com/Distributed-Search-Strategy---Shards-td18882112.html
> Solr seems to lock up when running distributed search on three servers, with
> all three using shards of each other. Thread dump attached.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
