Joan Balagueró wrote:
Hello,
We're using "IdleConnectionTimeoutThread".
The code is the following:
this.objHttp = new HttpClient(new MultiThreadedHttpConnectionManager());
this.ictt = new IdleConnectionTimeoutThread();
this.ictt.addConnectionManager(this.objHttp.getHttpConnectionManager());
this.ictt.setTimeoutInterval(10000);
this.ictt.setConnectionTimeout(20000);
If I'm right, thread that checks for idle connections starts every 10 seconds
and removes all idle connections with no activity for more than 20 seconds.
Is it OK? And if it's, how can I find out that idle connections are really
being removed?
I could see when we send a request with httpclient, the connection goes to
ESTABLISHED state, and when we release this connection, it goes to CLOSE_WAIT
state, and remains in this state for several minutes.
Are you sure the connection goes to CLOSE_WAIT state and not TIME_WAIT?
Is an idle connection a connection in CLOSE_WAIT state? If httpclient removes one idle
connection, must I suppose that the number of CLOSE_WAIT connections are decrement in 1?
(looking at them with the "netstat" linux statement).
Basicly, now my problem is I need to check that "IdleConnectionTimeoutThread "
is really removing idle connections, but I'm not sure how to do this.
Reusable connections are in the ESTABLISHED state, stale connections are
in the CLOSE_WAIT state (closed on the server side but still open on the
client side), closed connections should temporarily go into the
TIME_WAIT state and then be removed from the connection list
Another thing you told me was that I could use the method "closeIdleConnections(timeout)". I suppose that the
right way to do this is calling this method after "releaseConnection". Is this the correct way? And if it's,
is it optimal to call "closeIdleConnections" after every "releaseConnection"?
The best way is to call #closeIdleConnections _before_ executing a new
request after a period of inactivity.
Oleg
Thanks in advance,
Joan.
-----Mensaje original-----
De: Oleg Kalnichevski [mailto:[EMAIL PROTECTED]
Enviado el: viernes, 18 de julio de 2008 0:06
Para: HttpClient User Discussion
Asunto: RE: Pool running out of connections
On Thu, 2008-07-17 at 17:41 +0200, Joan Balagueró wrote:
Hello,
Thanks for your response. I suppose that this eviction policy that you are
saying is achieved by using IdleConnectionTimeoutThread. Am I right?
Joan.
Yes, you are. You do not necessarily need a special thread to achieve
that. Just call HttpConnectionManager#closeIdleConnections method after
a period inactivity to purge stale connections:
http://hc.apache.org/httpclient-3.x/apidocs/org/apache/commons/httpclient/HttpConnectionManager.html#closeIdleConnections(long)
Oleg
-----Mensaje original-----
De: Oleg Kalnichevski [mailto:[EMAIL PROTECTED]
Enviado el: miércoles, 16 de julio de 2008 18:03
Para: HttpClient User Discussion
Asunto: Re: Pool running out of connections
On Wed, 2008-07-16 at 09:03 +0200, Joan Balagueró wrote:
Hello,
We have developed software that uses HttpClient 3.1.
It has been working for 2 months. Recently though, we have been getting
'Maximum number of simultaneous requests exceeded' errors.
We are using a multi-threaded pool with 100 connections. Our application
never has more than 10 simultaneous requests.
The error is “Socked closed”. These connections were established on the
14th
of July. The shutdown was done on the 15th of July (in other words, these
connections were open for more than a day). What we don't understand is
how
it is possible that these connections can be open for so long when they
have
a timeout of 26 seconds (which we assign in the PostMethod).
Socket timeout applies to _active_ read operations only. Idle
connections cannot time out, as they are not blocked in a read
operation.
You should implement an eviction policy to close connections that have
been idle for too long.
Hope this helps
Oleg
---------------------------------------------------------------------
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]
---------------------------------------------------------------------
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]
