Ortwin Gl�ck write: > There is an option to disable stale checking. Thanks, though turning stale checking off doesn't change the outcome - the readResponse call still blocks for 30s. I don't think it's the stale checking that's causing the problem, but for some reason the server ignores or closes the connection after several minutes of inactivity.
Incidentally, I've tried to emulate this using IE 6, and I couldn't reproduce the problem. I believe this is because IE closes persistent connections itself after 60 seconds of inactivity. (See http://www.cs.wisc.edu/~cao/papers/persistent-connection.html. The paper discusses IE 4.01 - though using a network monitor I can confirm this is still true for IE 6.) But, Netscape 7.1 does have the problem. If I load a page from the server, wait a few minutes, and then try a reload, the browser hangs until the socket times out, just as HttpClient does. The network monitor shows the connection closed after a few minutes. As the socket is clearly closed, I have no idea why both netscape and HttpClient can't detect that the socket is closed. I hacked HttpConnection to include a check to call the methods Socket.isClosed/isConnected/isInputShutdown/isOutputShutdown to see if these help determine if the socket is close - all of these indicate that the socket is still alive, yet my network monitor indicates that the connection is closed. The only solution I can see is that perhaps HTTPClient could follow IE's approach and close & remove free connections from the connection manager pool after a configurable period of inactivity? Cheers, mat. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
