FYI, the fix is in there now (along with a bunch of new tests), and a new 'closeExpiredConnections' method that can be used the same way closeIdleConnections works if you want to bulk-close all expired connections at any given moment.
Sam On Wed, Jun 25, 2008 at 5:52 PM, Oleg Kalnichevski <[EMAIL PROTECTED]> wrote: > On Wed, 2008-06-25 at 17:42 -0400, Sam Berlin wrote: >> Done @ https://issues.apache.org/jira/browse/HTTPCLIENT-781 . I can >> take a look at this in the coming days -- do you think an >> implementation that just closes the prior connection & makes a new one >> on a subsequent request is OK, or does HttpClient need to close the >> connection immediately once the timeout elapses? (I don't think the >> latter is possible without an additional thread.) >> > > I think the former is good enough, but a possibility to introduce a more > sophisticated eviction policy would be an advantage. This however does > not seem to require changes in the public API so it could be done after > BETA1. What we need to do before the API freeze is to ensure there is a > way to set a timeout value on individual managed connections. > > Oleg > > >> Sam >> >> On Wed, Jun 25, 2008 at 5:33 PM, Oleg Kalnichevski <[EMAIL PROTECTED]> wrote: >> > On Wed, 2008-06-25 at 17:14 -0400, Sam Berlin wrote: >> >> Hi Folks, >> >> >> >> We just stumbled across an issue with persistent connections where the >> >> server is sending a Connection: Keep-Alive header, but also a >> >> Keep-Alive header with a timeout=## (and a max=##). HttpClient's >> >> connection management sees that the connection can be kept alive, so >> >> pools it for potential reuse, but doesn't respect the timeout (or max) >> >> values. The problem is that the connection remains opens from the >> >> eyes of HttpClient. A subsequent request sends correctly (with no >> >> IOX's, oddly enough), but reading causes HttpClient to read a -1 and >> >> throw a NoHttpResponseException. This is against a run-of-the-mill >> >> Apache httpd server. >> >> >> >> This is normally supposed to be handled by a HttpRequestRetryHandler, >> >> to retry to the connection, but I'm wondering if it shouldn't even get >> >> there in the first place. Should HttpClient respect the Keep-Alive >> >> header's timeout (and max, or other) token and use a new connection in >> >> the first place? >> >> >> > >> > Hi Sam >> > >> > We certainly need to fix that. Could you please open a JIRA for this >> > issue? >> > >> > Oleg >> > >> >> Sam >> >> >> >> --------------------------------------------------------------------- >> >> 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]
