hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Becke <be...@u.washington.edu>
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:34:00 GMT
Nice assessment of the problem Eric.

I agree that re-entrace is another big problem.  I don't think we've 
come across it yet but I definitely think that we will before long.

As you said, the real problem is that we're providing access to the real 
HttpConnection. This means we can only give it out but have to method 
for taking it away when closed.

I like your idea of wrapping the real connection in another layer.  I 
should have some time to try this out today.  I will post anything I 
come up with.

Mike

Eric Johnson wrote:
> 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
>>
>>  
>>
> 
> 
> ---------------------------------------------------------------------
> 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