This happens both under Tomcat and under Jetty. It happens sometimes when only two documents are being indexed at the same time, so it is not actually related to "load". It also seems to occur during connection setup rather than when there are established connections.
Karl On Tue, Jan 22, 2013 at 10:41 AM, Asankha C. Perera <[email protected]> wrote: > Hi Karl > > Is Solr hosted on Tomcat? and is Tomcat under any load / or properly tuned > to handle such load? How frequently does this occur? > > regards > asankha > > > On 01/22/2013 07:44 PM, Karl Wright wrote: >> >> Hi all, >> >> For the ManifoldCF release, we've been having problems with our Solr >> connector, which uses Solrj which in turn uses >> HttpComponents/HttpClient to connect to Solr. >> >> The behavior we've been seeing is that when multiple document uploads >> to Solr are taking place at the same time, we see SocketExceptions >> that we shouldn't be seeing. These are of the general "broken pipe" >> variety, and seem to be consistent with someone somewhere closing a >> socket that should not be getting closed. It is furthermore not clear >> whether the problem is on the client side or on the server side. >> >> On the client side, we have a connection pool and DefaultHttpClient >> instance per thread. I've reviewed all the code we use to set up the >> DefaultHttpClient and also the SolrJ code that performs the actual >> upload. While I can see where there might be issues (such as unclosed >> connections) under some usage scenarios, not only are we avoiding any >> of these questionable usage scenarios, but also we are never sharing >> HttpClient objects among threads. This leads me to believe that the >> problem is on the server side. However, this is difficult for my >> colleagues to accept, so I wish to ask the question: is it even >> possible for HttpClient to close sockets in a cross-thread manner? >> >> Also, FWIW, I believe that this issue may have been around a fairly >> long time, but has been masked by automatic retries in the past. >> >> Karl >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> >> > > > -- > Asankha C. Perera > AdroitLogic, http://adroitlogic.org > > http://esbmagic.blogspot.com > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
