hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject DO NOT REPLY [Bug 25370] - exception during writeRequest leaves the connection un-released
Date Wed, 10 Dec 2003 20:01:02 GMT
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=25370>.
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=25370

exception during writeRequest leaves the connection un-released

olegk@apache.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
   Target Milestone|---                         |2.1 Alpha 1
            Version|2.0 Milestone 2             |Nightly Builds



------- Additional Comments From olegk@apache.org  2003-12-10 20:01 -------
> if (CAUSE_RANDOM_ERROR) if (Math.random() > ERROR_RATE) throw new
> IOException("Random error, for testing only!");

OK. I see.

> From reading the code, it seems the outputstream is wrapped 
> insideWrappedOutputStream which rethrows any exceptions *inside its methods* 
> asrecoverable. There are two problems with this approach. 

Mohammad, actually that is that way it is supposed to be. IOException thrown
when retrieving request content or runtime exceptions are not recoverable HTTP
transport exceptions and should not be treated as such 

> Thanks for the clarification. You still have to be extremely careful if you
> enable auto recovery on write.

Agreed. I personally am not in favour of having auth-recovery activated per
default, but according to the feedback we were getting from our users the
majority did not appear to share that conviction.

> How about this fix: add
>                 catch (IOException e) {
>                     releaseConnection = true;
>                     throw e;
>                 } catch (RuntimeException e) {
>                     releaseConnection = true;
>                     throw e;
>                 }
> to the last try clause in HttpMethodDirector#executeWithRetry ?

That can be done. I would not like to change 2.0 branch, though, for the
following reason: the invocation of HttpClient#execute(HttpMethod) MUST be
followed by HttpMethod#releaseconnection regardless of the outcome (preferably
by calling it in the finally clause). This is a part of HttpClient API contract.
So, personally do not see this bug serious enough to warrant modification of
HttpClient 2.0 which is the release candidate phase.

Oleg

---------------------------------------------------------------------
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