[
https://issues.apache.org/jira/browse/SOLR-4328?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13561112#comment-13561112
]
Karl Wright commented on SOLR-4328:
-----------------------------------
I created a ManifoldCF test that creates a mock Solr web application, and then
indexes 100 documents. We do not see any IOException's from this test, on
either Windows or Ubuntu.
I think this proves conclusively that Solr itself is causing the problem.
Furthermore, when we change the client code so that connections are never
reused (at the expense, of course, of creating a new connection on every
operation), the problem goes away. It therefore seems clear that Solr is
closing the socket out from under the application server, so that client-side
connection pooling and re-use cannot be done properly.
> Simultaneous multiple connections to Solr example sometimes fail with various
> IOExceptions
> ------------------------------------------------------------------------------------------
>
> Key: SOLR-4328
> URL: https://issues.apache.org/jira/browse/SOLR-4328
> Project: Solr
> Issue Type: Bug
> Affects Versions: 4.0, 3.6.2
> Environment: ManifoldCF, Solr connector, SolrJ, and Solr 4.0 or 3.6
> on Mac OSX or Ubuntu, all localhost connections
> Reporter: Karl Wright
>
> In ManifoldCF, we've been seeing problems with SolrJ connections throwing
> java.net.SocketException's. See CONNECTORS-616 for details as to exactly
> what varieties of this exception are thrown, but "broken pipe" is the most
> common. This occurs on multiple Unix variants as stated. (We also
> occasionally see exceptions on Windows, but they are much less frequent and
> are different variants than on Unix.)
> The exceptions seem to occur during the time an initial connection is getting
> established, and seems to occur randomly when multiple connections are
> getting established all at the same time. Wire logging shows that only the
> first few headers are sent before the connection is broken. Solr itself does
> log any error. A retry is usually sufficient to have the transaction succeed.
> The Solr Connector in ManifoldCF has recently been upgraded to rely on SolrJ,
> which could be a complicating factor. However, I have repeatedly audited
> both the Solr Connection code and the SolrJ code for best practices, and
> while I found a couple of problems, nothing seems to be of the sort that
> could cause a broken pipe. For that to happen, the socket must be closed
> either on the client end or on the server end, and there appears to be no
> mechanism for that happening on the client end, since multiple threads would
> have to be working with the same socket for that to be a possibility.
> It is also true that in ManifoldCF we disable the automatic retries that are
> normally enabled for HttpComponents HttpClient. These automatic retries
> likely mask this problem should it be occurring in other situations.
> Places where there could potentially be a bug, in order of likelihood:
> (1) Jetty. Nobody I am aware of has seen this on Tomcat yet. But I also
> don't know if anyone has tried it.
> (2) Solr servlet. If it is possible for a servlet implementation to cause
> the connection to drop without any exception being generated, this would be
> something that should be researched.
> (3) HttpComponents/HttpClient. If there is a client-side issue, it would
> have to be because an httpclient instance was closing sockets from other
> instances.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
