Mailing-List: contact dev-help@hc.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "HttpComponents Project" <dev@hc.apache.org>
Received-SPF: pass (athena.apache.org: domain of daddywri@gmail.com designates
 209.85.220.177 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <1358938578.23247.7.camel@ubuntu>
References: 
 <CALUFAGAL0=-tmOJKcc4ZgH-PGiL5Tyw69vh8aMrkB_di36JA0w@mail.gmail.com>
	<1358938578.23247.7.camel@ubuntu>
Date: Wed, 23 Jan 2013 06:49:11 -0500
Message-ID: 
 <CALUFAGAiEQNaWoPq86giv9Z7qE_79j+Vwy80j4Jzw39=z7=Xcg@mail.gmail.com>
Subject: Re: Strange behavior - does this sound familiar to anyone?
From: Karl Wright <daddywri@gmail.com>
To: HttpComponents Project <dev@hc.apache.org>
Content-Type: text/plain; charset=ISO-8859-1

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 <olegk@apache.org> 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: 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
>

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