hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oleg Kalnichevski <ol...@apache.org>
Subject Re: Strange behavior - does this sound familiar to anyone?
Date Wed, 23 Jan 2013 10:56:18 GMT
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.


> 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: dev-unsubscribe@hc.apache.org
> For additional commands, e-mail: dev-help@hc.apache.org

To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org

View raw message