hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Eric Johnson <e...@tibco.com>
Subject Re: DO NOT REPLY [Bug 13463] - Request/Response race condition when doing multiple requests on the same connection.
Date Fri, 14 Feb 2003 14:17:29 GMT
Mike,

I agree with your assessment that it must necessarily be unsafe to call 
HttpConnection.releaseConnection() in a multithreaded environment. 
 Since only the method and its "stream" "knows" when its response has 
been fully consumed, you can never guarantee that the connection might 
be recycled at some point.  In some sense, this isn't really a 
multi-threading issue, so much as it is a sequencing issue.  Consider 
the following scenario.

Execute method A.
Save method A's "connection"
Fully read its response.

Execute method B - (happens to reuse connection from A)
"release" method A's connection as "cleanup" (we don't explicitly 
disallow this sequencing in the API).
read method B's response - exception thrown, as its connection was closed.

The only way that I can see around this is to change HttpConnection to 
be a facade around another class that looks a lot like its current 
implementation.  In that way, when a connection is "released", the 
facade can be put into a state where subsequent "releases" will be 
ignored, however the underlying "HttpConnection" may already be in use 
elsewhere - by a different thread or subsequent request in the same thread.

Also, the HttpConnection has a "lastResponseInputStream" - calling 
"close" on that stream (if there is one), will result in a notification 
to the method that the response has been consumed.  The only trick here 
is a re-entrance problem.  When the method sees that the response body 
has been consumed, it releases the connection.  As a result, you don't 
want HttpConnection.releaseConnection() to call 
lastResponseInputStream.close(), or you don't want the HttpMethodBase to 
call HttpConnection.releaseConnection().  A different function on 
HttpConnection, specifically for the method releasing the connection, 
might solve that problem - methodDoneWithConnection(), or some such thing.

As for the NPE that Aurélien Pernoud noted, I'm not sure where that is 
coming from.

I might have a chance to look at these problems later today, but if 
someone else out there has time sooner, that would likely be better, as 
there is a good chance I won't get to look at this until Tuesday of next 
week.  Hopefully the above is helpful enough to get someone else going 
in the right direction.

-Eric.

bugzilla@apache.org wrote:

>DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
>RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
><http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13463>.
>ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
>INSERTED IN THE BUG DATABASE.
>
>http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13463
>
>Request/Response race condition when doing multiple requests on the same connection.
>
>
>
>
>
>------- Additional Comments From becke@u.washington.edu  2003-02-14 02:04 -------
>Ok, I think I've figured it out.  It seems that calling
>HttpConnection.releaseConnection() is inherently unsafe.  Connections are used
>on a per method basis but have no reference to the method they are being used
>by.  Here's a scenario:
>
>1) A method (A) gets a connection from the connectionManager
>2) A is executed
>3) The response from A is read fully and the connection is implicitly released
>4) The released connection is given to another method (B)
>5) Following the execution of A the user code calls
>HttpConnection.releaseConnection()
>6) The connection is released again
>7) B executes but is using a released connection
>
>As you can see the connection was released twice for the method A.  Currently
>there is no way for a connection to know that it has already been released from
>a particular method.  This is not a problem if the
>HttpMethod.releaseConnection() is always used, since it knows to only release
>its connection once.
>
>So, for a quick fix, HttpConnection.releaseConnection() should not be used in
>client code.  I'll try to come up with a solution that fixes it, but we may just
>have to remove it from public consumption.
>
>Mike
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: commons-httpclient-dev-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: commons-httpclient-dev-help@jakarta.apache.org
>
>  
>


Mime
View raw message