On Wed, Dec 14, 2005 at 09:22:39AM +0100, Ephemeris Lappis wrote: > Hello. > > > > This issue has already bean discussed in the past, but I have not found any > actual solution to solve it. So, if someone has a new idea, it's welcome! > > > > The problem occurs with pooled connections, using a > MultiThreadedHttpConnectionManager. Connections are created according to the > client requests load, and kept in pool. After a given delay, about 15 or 20 > seconds on Tomcat or Apache, the server dismisses old connections. At the > other end, the http-client doesn't seem to detect the unilateral server's > closing action, and send the new request: I don't understand how this can > work !
The trouble is there is no way (I personally know of) to detect this event in Java. The only reliable to way to test if a socket is still valid is to perform a read operation on it. This is essentially what the stale connection check is all about Then, as from the server's point of view the connection is closed, > nothing comes back, and the http-client fails reading the response. It > throws a HttpRecoverableException, with the well known specific message: > Error in parsing the status line from the response: unable to find line > starting with "HTTP". Activating the stale connections checking fixes the > problem, but induces an unacceptable performance down: requests that are > processed in less than 1 ms take over 20-30 ms with checking. Another > possible solution is not managing connections at all, using HTTP 1.0 and no > connection manager, but this also leads to slower processing and, above all, > excessive TCP/IP system resources waste. > > > > Note this occurs with JDK 1.3, 1.4 or 5.0. > > > > Is there any way to make the http-client handle such server's close, and > avoid using a doubtful socket? > > > > I think an "acceptable" solution should be to limit the reuse of pooled > connections giving them a maximum life-time (from the creation time) or > inactivity delay (since last request): when the manager gets a connection > from the pool, it should check the connection age, and discard it if too > old. > > This feature has been implemented in HttpClient 3.0. Consider upgrading. > > I've had a look to the library's sources to evaluate such a solution, but > its design disallow extension since all the connection pool and adapter > classes, and instantiation and selection policies are all private inside the > manager code. > > I assume you have been looking at the HttpClient 2.0.2 source code? Oleg > > Your comment and ideas are all welcome ! > > > > Thanks. > > > > -- > > Ephemeris Lappis > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
