Yep, seems to make sense. Odi
Oleg Kalnichevski wrote:
Folks, The message I am forwarding was sent to the HttpClient user list a while ago. I think the changes proposed by Balazs are very reasonable. Unfortunately Balazs never submitted the patch and did not return emails I had sent him off-list. Nonetheless, I think we should consider changing MultithreadedConnectionManager's behavior as proposed by Balazs and include those changes into 3.1-beta1 Mike, what do you think? Oleg -------- Forwarded Message -------- From: SZÜCS Balazs <[EMAIL PROTECTED]> Reply-To: HttpClient User Discussion <httpclient-user@jakarta.apache.org> To: 'HttpClient User Discussion' <httpclient-user@jakarta.apache.org> Subject: RE: MultithreadedConnectionManager pooling strategy Date: Mon, 15 May 2006 15:26:08 +0200 Hello, I made two changes to the HttpClient code: 1) in the class ConnectionPool in the method getFreeConnection( ... ) I changed freeConnections.removeFirst() to freeConnections.removeLast(). Now the container for free connections behaves as a stack rather than a queue. 2) additionally I changed the IdleConnectionTimeoutThread, in the run() method I added connectionManager.deleteClosedConnections() so that the pool size is maintained correctly. What do you think? Balazs -----Original Message-----From: Oleg Kalnichevski <[EMAIL PROTECTED]>@DSI Sent: Donnerstag, 04. Mai 2006 18:07To: HttpClient User Discussion Subject: Re: MultithreadedConnectionManager pooling strategy On Thu, 2006-05-04 at 18:00 +0200, SZÜCS Balazs wrote: > Hello, > > I'm using HttpClient 3.0-rc4, and I have a question about the connection > pooling strategy of MultithreadedConnectionManager. The reason for that is > that I use an IdleConnectionTimeoutThread (runs every 60 secs, using a > timeout of 60 secs) configured with a MultithreadedConnectionManager, and > idle connections don't seem to get closed by the > IdleConnectionTimeoutThread. However, on a long time span (overnight) the > pool size decreases, but I would expect a quicker reaction, when my > application is not unter heavy load. > > I've taken a look at the source of MultithreadedConnectionManager, and I > realized, that free connections are stored in a linked list. On demand the > next free connection is taken from the BEGINNING of the list, while after > usage the connection is put back to the END of the list. This seems to me a > round robin behavior, and it might prevent connections reaching the > predefined age for being recognized as idle. If there is some load, each > free connection will be used, instead of just using a few of them, and > letting the rest age. > > Does that make any sense? > Balazs, Yes, it does. Please file a bug report in Bugzilla. Feel free to provide a patch for the problem. We love patches ;-) Oleg > Thank you! > > Balazs --------------------------------------------------------------------- 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]
-- [web] http://www.odi.ch/ [blog] http://www.odi.ch/weblog/ [pgp] key 0x81CF3416 finger print F2B1 B21F F056 D53E 5D79 A5AF 02BE 70F5 81CF 3416 --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
