Hello, Then, I understand that idle connections are in ESTABLISHED state.
I could try: this.ictt.setTimeoutInterval(1000); this.ictt.setConnectionTimeout(1); This should eliminate all established connections every second. As I told you our problem is that, with our app, we don't know why connections remain in ESTABLISHED state for hours and hours. Do you think this test could help me? Thanks, Joan. -----Mensaje original----- De: Oleg Kalnichevski [mailto:[EMAIL PROTECTED] Enviado el: martes, 29 de julio de 2008 13:12 Para: HttpClient User Discussion Asunto: Re: Pool running out of connections 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] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
