Thanks, Oleg. I was already aware of that. Architecturally it should not be possible to share HttpClient objects among threads in this situation.
Karl On Wed, Jan 23, 2013 at 5:56 AM, Oleg Kalnichevski <[email protected]> wrote: > On Tue, 2013-01-22 at 09:14 -0500, 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? >> > > Http connections created by HttpClient are not thread safe (with an > exception of #shutdown method). HttpClient takes special precautions to > make sure connections cannot end up being accessed by multiple threads. > Under normal circumstances client HTTP connection should never be used > by more than one thread. > > I am sorry I cannot be of any better help. > > Oleg > >> 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] >> > > > > --------------------------------------------------------------------- > 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]
