You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hc.apache.org by Yue Luo <yu...@sun.com> on 2003/08/29 19:33:19 UTC
A bug?
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.
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?
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.
Thanks.
Yue
Re: A bug?
Posted by Yue Luo <yu...@sun.com>.
>> 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?
Closing the output may close the input too. But this is not problem.
You can usually close a closed stream. The original problem is caused
by flush(). Because the output stream is a buffered stream, when you
close it, it will try to flush its content before really close. This
flush caused exception, not the close itself.
Yue
Re: A bug?
Posted by Oleg Kalnichevski <ol...@apache.org>.
Roland, Mike and all.
Not only it appears to be a reasonable order of things, it also seems to
correspond to Sun's official recommendations
...
out.close();
in.close();
...
echoSocket.close();
...
These statements close the readers and writers connected to the socket
and to the standard input stream, and close the socket connection to the
server. <Strong>The order here is important</Strong>. You should close
any streams connected to a socket before you close the socket itself.
...
Java tutorial
<http://java.sun.com/docs/books/tutorial/networking/sockets/readingWriting.html>
On Tue, 2003-09-02 at 07:19, Roland Weber wrote:
> Hello Mike,
>
> I think closing the output stream first is the right thing to do.
> Someone might want to send a shutdown notification to the
> server before stopping to receive, e.g. for SSL connections.
>
> regards,
> Roland
>
>
>
>
>
> Michael Becke <be...@u.washington.edu>
> 01.09.2003 21:16
> Please respond to "Commons HttpClient Project"
>
> To: "Commons HttpClient Project"
> <co...@jakarta.apache.org>
> cc:
> Subject: Re: A bug?
>
>
> Yes, this is a good point. We might as well be as thorough as possible.
>
> The only real change that might make sense in reversing the order in
> which streams are closed. Is sounds like Yue would like to have the
> output stream closed before the input. Anyone have objections to this?
>
> Mike
>
> On Monday, September 1, 2003, at 07:46 AM, Roland Weber wrote:
>
> > Michael Becke wrote:
> >
> >> Any thoughts on why we close the streams and then the socket?
> >
> > Someone might have implemented sockets with buffered streams.
> > Closing only the socket directly would not dispose of the buffers.
> > Given the SocketFactory stuff, that possibility shouldn't be ruled out.
> >
> > just my thoughts :-)
> > Roland
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> commons-httpclient-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail:
> commons-httpclient-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-httpclient-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-httpclient-dev-help@jakarta.apache.org
Re: A bug?
Posted by Michael Becke <be...@u.washington.edu>.
Sounds reasonable. I will go ahead and create patch for this.
Thanks,
Mike
On Tuesday, September 2, 2003, at 01:19 AM, Roland Weber wrote:
> Hello Mike,
>
> I think closing the output stream first is the right thing to do.
> Someone might want to send a shutdown notification to the
> server before stopping to receive, e.g. for SSL connections.
>
> regards,
> Roland
>
>
>
>
>
> Michael Becke <be...@u.washington.edu>
> 01.09.2003 21:16
> Please respond to "Commons HttpClient Project"
>
> To: "Commons HttpClient Project"
> <co...@jakarta.apache.org>
> cc:
> Subject: Re: A bug?
>
>
> Yes, this is a good point. We might as well be as thorough as
> possible.
>
> The only real change that might make sense in reversing the order in
> which streams are closed. Is sounds like Yue would like to have the
> output stream closed before the input. Anyone have objections to this?
>
> Mike
>
> On Monday, September 1, 2003, at 07:46 AM, Roland Weber wrote:
>
>> Michael Becke wrote:
>>
>>> Any thoughts on why we close the streams and then the socket?
>>
>> Someone might have implemented sockets with buffered streams.
>> Closing only the socket directly would not dispose of the buffers.
>> Given the SocketFactory stuff, that possibility shouldn't be ruled
>> out.
>>
>> just my thoughts :-)
>> Roland
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> commons-httpclient-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail:
> commons-httpclient-dev-help@jakarta.apache.org
>
>
Re: A bug?
Posted by Roland Weber <RO...@de.ibm.com>.
Hello Mike,
I think closing the output stream first is the right thing to do.
Someone might want to send a shutdown notification to the
server before stopping to receive, e.g. for SSL connections.
regards,
Roland
Michael Becke <be...@u.washington.edu>
01.09.2003 21:16
Please respond to "Commons HttpClient Project"
To: "Commons HttpClient Project"
<co...@jakarta.apache.org>
cc:
Subject: Re: A bug?
Yes, this is a good point. We might as well be as thorough as possible.
The only real change that might make sense in reversing the order in
which streams are closed. Is sounds like Yue would like to have the
output stream closed before the input. Anyone have objections to this?
Mike
On Monday, September 1, 2003, at 07:46 AM, Roland Weber wrote:
> Michael Becke wrote:
>
>> Any thoughts on why we close the streams and then the socket?
>
> Someone might have implemented sockets with buffered streams.
> Closing only the socket directly would not dispose of the buffers.
> Given the SocketFactory stuff, that possibility shouldn't be ruled out.
>
> just my thoughts :-)
> Roland
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail:
commons-httpclient-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail:
commons-httpclient-dev-help@jakarta.apache.org
Re: A bug?
Posted by Michael Becke <be...@u.washington.edu>.
Yes, this is a good point. We might as well be as thorough as possible.
The only real change that might make sense in reversing the order in
which streams are closed. Is sounds like Yue would like to have the
output stream closed before the input. Anyone have objections to this?
Mike
On Monday, September 1, 2003, at 07:46 AM, Roland Weber wrote:
> Michael Becke wrote:
>
>> Any thoughts on why we close the streams and then the socket?
>
> Someone might have implemented sockets with buffered streams.
> Closing only the socket directly would not dispose of the buffers.
> Given the SocketFactory stuff, that possibility shouldn't be ruled out.
>
> just my thoughts :-)
> Roland
>
>
Re: A bug?
Posted by Roland Weber <RO...@de.ibm.com>.
Michael Becke wrote:
> Any thoughts on why we close the streams and then the socket?
Someone might have implemented sockets with buffered streams.
Closing only the socket directly would not dispose of the buffers.
Given the SocketFactory stuff, that possibility shouldn't be ruled out.
just my thoughts :-)
Roland
Re: A bug?
Posted by Michael Becke <be...@u.washington.edu>.
Hi Yue,
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