hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Eric Johnson <e...@tibco.com>
Subject Re: connection leak in HttpMethodBase when HttpRecoverableException is re-thrown
Date Wed, 24 Sep 2003 18:26:45 GMT
Danch,

Note the bugs:
http://issues.apache.org/bugzilla/show_bug.cgi?id=23137
http://issues.apache.org/bugzilla/show_bug.cgi?id=22841

If you can, pull the latest code from CVS, or grab a nightly build, and 
try it again, as the bug may very well be fixed already.

Let us know how it goes.

- Eric

danch wrote:

> Hello,
> I'm using HttpClient (2.0 rc1) under Axis (using their 
> CommonsHttpSender class) and we've run into some problems with a web 
> application locking up (deadlock).
>
> A little research and a test application revealed that this our 
> application arrived at this condition after receiving a couple of 
> exceptions from HttpMethodBase.processRequest. If processRequest 
> catches an HttpRecoverableException, it attempts to determine whether 
> a retry should be attempted or not, and if not (which is our case), it 
> rethrows the exception, which is propogated on up the stack:
>
> } catch (HttpRecoverableException httpre) {
> if (LOG.isDebugEnabled()) {
> LOG.debug("Closing the connection.");
> }
> connection.close();
> LOG.info("Recoverable exception caught when processing request");
> // update the recoverable exception count.
> recoverableExceptionCount++;
>
> // test if this method should be retried
> if (!getMethodRetryHandler().retryMethod(
> this,
> connection,
> httpre,
> execCount,
> requestSent)
> ) {
> LOG.warn("Recoverable exception caught but 
> MethodRetryHandler.retryMethod() "
> + "returned false, rethrowing exception"
> );
> throw httpre;
> }
> }
>
>
> The caller of processRequest (HttpMethodBase.execute) does not handle 
> the exception, but has the following finally block:
>
> } finally {
> inExecute = false;
> // If the response has been fully processed, return the connection
> // to the pool. Use this flag, rather than other tests (like
> // responseStream == null), as subclasses, might reset the stream,
> // for example, reading the entire response into a file and then
> // setting the file as the stream.
> if (doneWithConnection) {
> ensureConnectionRelease();
> }
> }
>
>
> Note that the retry case is handled internally to 
> HttpMethodBase.execute. I believe that the
> 'doneWithConnection flag should be set to true before rethrowing the 
> HttpRecoverableException in the above catch block, so that the 
> connection will be released properly. This change seems to have solved 
> the problem we were having. Here's diff -u output
>
> --- HttpMethodBase.java 2003-09-24 13:10:10.249937500 -0500
> +++ HttpMethodBase.mine 2003-09-23 16:51:31.394929000 -0500
> @@ -2644,6 +2644,7 @@
> "Recoverable exception caught but MethodRetryHandler.retryMethod() "
> + "returned false, rethrowing exception"
> );
> + doneWithConnection = true;
> throw httpre;
> }
> }
>
>
> thanks,
> danch
>
>
> ---------------------------------------------------------------------
> 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