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.

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.


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"?


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]

Reply via email to