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 <[EMAIL PROTECTED]>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 <[EMAIL PROTECTED]>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: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> >
