Mailing-List: contact httpclient-users-help@hc.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "HttpClient User Discussion" <httpclient-users@hc.apache.org>
Received-SPF: pass (athena.apache.org: domain of kdobrik.axis2@googlemail.com
 designates 72.14.204.171 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=googlemail.com; s=gamma;
        h=message-id:date:from:to:subject:in-reply-to:mime-version
         :content-type:references;
        b=BtceCYQgKwNl4rnka7XUATkrkx/f/Rt+V9W4pHaJ3hWADFDCfAVUd7I5FUJCUqD0GO
         uQvWpWS7N2bnKN2N9nMywMvGuepxI7dxArIvO8vFNFEUBhtzETeMocU6CDrA+RmXHG2R
         1sEKk+LzfWfXvnFBK++nRBISX3pPzlg7NCrYY=
Message-ID: <3b3bfaf80809010727i63686b1as1e4f8b69ed424c6e@mail.gmail.com>
Date: Mon, 1 Sep 2008 17:27:23 +0300
From: "Dobri Kitipov" <kdobrik.axis2@googlemail.com>
To: "HttpClient User Discussion" <httpclient-users@hc.apache.org>
Subject: Re: "Keep-alive", stale connections and socket reuse
In-Reply-To: <3b3bfaf80809010633k47e1a7ffx7b6e334169f04c55@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_Part_55520_3428871.1220279243987"
References: <3b3bfaf80808280451n3febd120l5236cbf7a230e774@mail.gmail.com>
	 <1220008289.7914.16.camel@ubuntu>
	 <3b3bfaf80809010633k47e1a7ffx7b6e334169f04c55@mail.gmail.com>

------=_Part_55520_3428871.1220279243987
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Hi Oleg,
I have one additional more abstract question. What I have observed during my
tests was that when I run my test scenarion with 5 WS consecutive
invocations and sniff the traffic I can see that the sockets were reused.
The problem is that when I first tried to debug the source it always invoked
the org.apache.commons.httpclient.HttpConnection isStale() method. This is
happening when there are more breakpoints set. If I set only a breakpoint
into the isStale() method then the socket is reused and no new connection is
opened for every invocation. It seems it is a timeout issue or a thread
issue to me? Do you suspect what may cause this? I have tried to set
SO_TIMEOUT and CONNECTION_TIMEOUT to 0, but without success. Any hints?

Thank you in advance.
Regards,
Dobri

On Mon, Sep 1, 2008 at 4:33 PM, Dobri Kitipov
<kdobrik.axis2@googlemail.com>wrote:

> Hi Oleg,
> thank you for the detailed answer of my question.
> It seems we need to recommend the Axis2 guys to use the better version. Do
> you know when there will be an official release of HttpClient 4.0-beta1?
>
> Thank you,
> Dobri
>
>
> On Fri, Aug 29, 2008 at 2:11 PM, Oleg Kalnichevski <olegk@apache.org>wrote:
>
>> On Thu, 2008-08-28 at 14:51 +0300, Dobri Kitipov wrote:
>> > Hi,
>> >
>> > I am trying to explain myself how the "keep-alive", or TCP connection
>> > persistence, is supposed to work? I have read several resources about
>> that,
>> > but I still have some questions (
>> > http://java.sun.com/j2se/1.5.0/docs/guide/net/http-keepalive.html
>> >
>> > http://hc.apache.org/httpclient-3.x/performance.html
>> >
>> > http://www.io.com/~maus/HttpKeepAlive.html<http://www.io.com/%7Emaus/HttpKeepAlive.html>
>> <http://www.io.com/%7Emaus/HttpKeepAlive.html>
>> > ).
>> >
>> >
>> >
>> > How can I verify that "keep-alive" is really used? I know that for http
>> 1.1
>> > keep-alive is by default, but does it mean that the TCP socket is
>> reused?
>>
>> Yes, it does.
>>
>> >  I
>> > mean how can I debug and verify that a TCP connection is reused. Does it
>> > mean that a socket is reused?
>> >
>>
>> Turning on the context logging would be one option.
>>
>> >
>> >
>> > I have executed several debug sessions using as a sample an Axis2 1.4
>> > client, that in turns uses commons-httpclient-3.1.
>> >
>> > When I set client option:
>> >
>> >
>> >
>> > options.setProperty(HTTPConstants.REUSE_HTTP_CLIENT, "true");
>> >
>> >
>> >
>> > Having two web services invocations from my client I can see that the
>> > HttpClient is really reused when the prop is set. The http connection
>> used
>> > is of type MultiThreadedHttpConnectionManager$HttpConnectionAdapter
>> >
>> > The problem is that here stale connection check is enabled, so when the
>> > check is done as a consequence the connection (and its corresponding
>> socket)
>> > used is closed and a new one is opened.
>> >
>> >
>>
>> In some cases the stale connection check can report a perfectly valid
>> connection as stale. I would strongly recommend disabling it.
>>
>>
>> >
>> > I can read from
>> http://hc.apache.org/httpclient-3.x/preference-api.htmlthat:
>> >
>> >
>> >
>> > "Disabling stale connection check may result in *slight*
>> > *performance*improvement at the risk of getting an I/O error when
>> > executing a request
>> > over a connection that has been closed at the server side."
>> >
>> >
>> >
>> > My general understanding is that in order to have a better performance a
>> > connection should be reused and its socket,too?
>> >
>> >
>>
>> Yes.
>>
>> >
>> > My question is if it is a bad practice to disable stale connection check
>> in
>> > order to reuse the connection and its socket?
>>
>> No, it is not. You just have to make sure your application can react
>> intelligently to I/O exceptions caused by attempts to re-use a stale
>> connection.
>>
>>
>> >  Why in commons-httpclient it
>> > is preferred to close and open a new connection:
>> >
>>
>> Only if a connection is believed to have been closed on the other end
>> (is stale).
>>
>> >
>> >
>> >
>> > Where I can read more about the benefit/tradeoff of having stale conn
>> check?
>> >
>>
>> It is recommended to have a reasonable recovery strategy or/and eviction
>> policy for idle connections in place instead of relying on relatively
>> expensive and not always reliable stale connection check.
>>
>> Hope this helps
>>
>> Oleg
>>
>> PS: You may also consider upgrading to HttpClient 4.0-beta1 which has a
>> _much_ better and robust connection management code compared to
>> HttpClient 3.x.
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
>> For additional commands, e-mail: httpclient-users-help@hc.apache.org
>>
>>
>

------=_Part_55520_3428871.1220279243987--