Hello Guillaume,
Closing idle connections may also be of use. This feature has been added in HttpClient 3.0alpha2 and the forthcoming HttpClient 2.0.2 via HttpConnectionManager.closeIdleConnections() and the o.a.c.httpclient.util.IdleConnectionTimeoutThread.
Mike
On Oct 1, 2004, at 6:57 AM, Guillaume Cottenceau wrote:
Hello,
We use HttpClient for performing several HTTP post in parallel in our applications. We have a problem when the server(s) receiving our HTTP post either answers very slowly, or goes mad and sends garbage data over and over: the connection stays open forever, but more important, the Java threads as well. We have situations where we reach the maximum of Java threads our (tomcat) application is configured to handle, and our whole application is then unusable.
It seems that java.nio is capable of using only one thread for several lowlevel (OS) socket connections, and is actually also quite efficient.
I have seen that Oleg Kalnichevski has already expressed his views several times on the subject, and I have seen that you want to keep 1.2 compatibility, so java.nio out.
http://www.mail-archive.com/[EMAIL PROTECTED]/ msg05551.html
http://www.mail-archive.com/[EMAIL PROTECTED]/ msg06998.html
(btw, I don't agree with "in my opinion there's absolutely nothing that NIO can bring in in terms of performance to client-side applications" - well I agree that pure "performance" is not the problem but threads and memory consumption surely is - so in my opinion there is a lot to win with java.nio in httpclient)
My question is, since you don't want to lose 1.2 compatibility before 4.0, is there then a way to solve a typical "too many threads" problem such as the one we have? Do you people never had the same problem? Or have found a way to solve it?
It seems the HTTP protocol doesn't have anything resembling a "global timeout" for a given connection (e.g. after x seconds, close the receiving channel even if server hasn't finished sending), and thus normally httpclient doesn't provide such a thing. Do you think this should be investigated/implemented in some way?
Thanks, and best regards.
-- Guillaume Cottenceau
---------------------------------------------------------------------
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]
