Yue Luo wrote:
Hi,
Version 2.0-rc1
When HttpConnection.closeSocketAndStream() is called, it first closes the input stream, and then it closes the output stream. When I am using JSSE, the output stream seems to be also closed by the underlying system when the input stream is closed. So when this method tries to close the output stream ( a buffered stream), flush() method will be called first implicitly. Then an IOException will be thrown because the underlying stream is considered closed. WrappedOutputStream.flush() will catch the exception and then WrappedOutputStream.handleException() will be called to convert the exception to a HttpRecoverableException.
Yes, this is something we have noticed before. For a while there we had a problem where closing a socket would cause an infinite loop because of this. close->WrappedOutputStream.handleException->close->....
This exception is throw in perfect normal working condition, so I suppose it is a bug, although the end user will not notice it. I would suggest closing output stream before closing input stream in HttpConnection.closeSocketAndStream().
I am curious, is it really necessary to close the streams separately? Or can we just close the socket directly?
As you note, this is not really a problem as all IOExceptions caused during close are buried. It would be nice if this worked a little more cleanly though. I have no idea why we close all of the various streams and then the socket. It does seems a little redundant. Does closing the output not close the input in this case?
Any thoughts on why we close the streams and then the socket?
Another minor typo bug, the LOG message in HttpMethodBase.readResponseBody(HttpConnection conn) is wrong. It is for the other method with the same name. It is probably a copy & paste bug.
Quite right.
Thanks,
Mike
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
