Ok.. I had the same gut feeling when I put that in back in the 3.1 era.. 1) going to go look for that configuration (instructing HttpClient not to use connections idle longer than 20,000ms). 2) change the idle to check each minute..
Just to be safe.. If I have a pool of 5 connections and tell it not to use connections idle longer than 20,000ms is there a chance I would run out of entries in the pool before they were evicted and refreshed? Will it just ignore the pool size and open new connections if all 5 connections are either active or idle longer than 20,000ms? -k -----Original Message----- From: Oleg Kalnichevski [mailto:[email protected]] Sent: Wednesday, May 26, 2010 1:05 PM To: HttpClient User Discussion Subject: RE: java.lang.IllegalStateException: Connection already open On Wed, 2010-05-26 at 11:01 -0400, Brooks, Kenneth S wrote: > Attaching 2 log snippets. > > First is the httpclient log with log4j.logger.org.apache.http=TRACE, F as the > log4j setting. I've included the very last line of the wire trace from the > previous call.. just to give some conetext. I think what you are looking for > is right around: 2010-05-22 16:41:03,411 > > The second is our client logs, just to show when the call was attempted and > failed with the IllegalStateException. > > FYI my idleconnectionhandler is running every 1000ms and evicting anything > older than 20,000ms. > Ken I took a cursory look at the log and even though I have not yet found the cause of the race condition, I am at least pretty sure I know why it has gone undetected for so long. Your idle connection checks are waaaaay too aggressive. It is really unnecessary to run the checks so often. Once a minute should be enough, let alone every second. If you want to make sure persistent connections do not get stale, you can simply instruct HttpClient to not re-use connections that have been idle longer than, say, 20,000ms but actively evict connections from the pool only once a minute or so. The idle connection handler in your configuration puts unnecessary load on the connection pool and degrades performance. Oleg --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected] This transmission may contain information that is privileged, confidential, legally privileged, and/or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is STRICTLY PROHIBITED. Although this transmission and any attachments are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by JPMorgan Chase & Co., its subsidiaries and affiliates, as applicable, for any loss or damage arising in any way from its use. If you received this transmission in error, please immediately contact the sender and destroy the material in its entirety, whether in electronic or hard copy format. Thank you.
