You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hc.apache.org by "Jason Bird (JIRA)" <ji...@apache.org> on 2006/12/13 01:43:21 UTC
[jira] Created: (HTTPCLIENT-616)
HttpMethodDirector.executeWithRetry method fails to close the underlying
connection if a RuntimeException is thrown
HttpMethodDirector.executeWithRetry method fails to close the underlying connection if a RuntimeException is thrown
-------------------------------------------------------------------------------------------------------------------
Key: HTTPCLIENT-616
URL: http://issues.apache.org/jira/browse/HTTPCLIENT-616
Project: HttpComponents HttpClient
Issue Type: Bug
Affects Versions: 3.1 Beta 1
Environment: All
Reporter: Jason Bird
The following code snippet is from the end of the HttpMethodDirector.executeWithRetry method:
} catch (IOException e) {
if (this.conn.isOpen()) {
LOG.debug("Closing the connection.");
this.conn.close();
}
releaseConnection = true;
throw e;
} catch (RuntimeException e) {
if (this.conn.isOpen) { <<<=========================== BAD! :-)
LOG.debug("Closing the connection.");
this.conn.close();
}
releaseConnection = true;
throw e;
}
When an IOException is caught, you can see that the "open" status of the connection is accurately checked by calling the "isOpen()" method.
When a RuntimeException is caught, however, the code mistakenly checks only the "isOpen" member field. In the case where "conn" is, for example, a MultiThreadedHttpConnectionManager, the "isOpen()" method is overridden to check for a wrapped connection and returns the "isOpen" status of that connection. In cases like that checking the "isOpen" member field is obviously wrong and we end up not calling "close()" and the connection is not cleaned up. This causes issues with later calls.
A very difficult bug to diagnose and <steps up on soapbox> one that could have been easily avoided by making member variables private! <steps down> thank you. :-)
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org
[jira] Resolved: (HTTPCLIENT-616)
HttpMethodDirector.executeWithRetry method fails to close the underlying
connection if a RuntimeException is thrown
Posted by "Oleg Kalnichevski (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/HTTPCLIENT-616?page=all ]
Oleg Kalnichevski resolved HTTPCLIENT-616.
------------------------------------------
Resolution: Fixed
Fix applied. Many thanks, Jason
Oleg
> HttpMethodDirector.executeWithRetry method fails to close the underlying connection if a RuntimeException is thrown
> -------------------------------------------------------------------------------------------------------------------
>
> Key: HTTPCLIENT-616
> URL: http://issues.apache.org/jira/browse/HTTPCLIENT-616
> Project: HttpComponents HttpClient
> Issue Type: Bug
> Components: HttpClient
> Affects Versions: 3.1 Beta 1
> Environment: All
> Reporter: Jason Bird
> Fix For: 3.1 Final
>
>
> The following code snippet is from the end of the HttpMethodDirector.executeWithRetry method:
> } catch (IOException e) {
> if (this.conn.isOpen()) {
> LOG.debug("Closing the connection.");
> this.conn.close();
> }
> releaseConnection = true;
> throw e;
> } catch (RuntimeException e) {
> if (this.conn.isOpen) { <<<=========================== BAD! :-)
> LOG.debug("Closing the connection.");
> this.conn.close();
> }
> releaseConnection = true;
> throw e;
> }
> When an IOException is caught, you can see that the "open" status of the connection is accurately checked by calling the "isOpen()" method.
> When a RuntimeException is caught, however, the code mistakenly checks only the "isOpen" member field. In the case where "conn" is, for example, a MultiThreadedHttpConnectionManager, the "isOpen()" method is overridden to check for a wrapped connection and returns the "isOpen" status of that connection. In cases like that checking the "isOpen" member field is obviously wrong and we end up not calling "close()" and the connection is not cleaned up. This causes issues with later calls.
> A very difficult bug to diagnose and <steps up on soapbox> one that could have been easily avoided by making member variables private! <steps down> thank you. :-)
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org
[jira] Updated: (HTTPCLIENT-616)
HttpMethodDirector.executeWithRetry method fails to close the underlying
connection if a RuntimeException is thrown
Posted by "Oleg Kalnichevski (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/HTTPCLIENT-616?page=all ]
Oleg Kalnichevski updated HTTPCLIENT-616:
-----------------------------------------
Component/s: HttpClient
Fix Version/s: 3.1 Final
Uh. This is a pretty bad one. Many thanks for tracking it down
Oleg
> HttpMethodDirector.executeWithRetry method fails to close the underlying connection if a RuntimeException is thrown
> -------------------------------------------------------------------------------------------------------------------
>
> Key: HTTPCLIENT-616
> URL: http://issues.apache.org/jira/browse/HTTPCLIENT-616
> Project: HttpComponents HttpClient
> Issue Type: Bug
> Components: HttpClient
> Affects Versions: 3.1 Beta 1
> Environment: All
> Reporter: Jason Bird
> Fix For: 3.1 Final
>
>
> The following code snippet is from the end of the HttpMethodDirector.executeWithRetry method:
> } catch (IOException e) {
> if (this.conn.isOpen()) {
> LOG.debug("Closing the connection.");
> this.conn.close();
> }
> releaseConnection = true;
> throw e;
> } catch (RuntimeException e) {
> if (this.conn.isOpen) { <<<=========================== BAD! :-)
> LOG.debug("Closing the connection.");
> this.conn.close();
> }
> releaseConnection = true;
> throw e;
> }
> When an IOException is caught, you can see that the "open" status of the connection is accurately checked by calling the "isOpen()" method.
> When a RuntimeException is caught, however, the code mistakenly checks only the "isOpen" member field. In the case where "conn" is, for example, a MultiThreadedHttpConnectionManager, the "isOpen()" method is overridden to check for a wrapped connection and returns the "isOpen" status of that connection. In cases like that checking the "isOpen" member field is obviously wrong and we end up not calling "close()" and the connection is not cleaned up. This causes issues with later calls.
> A very difficult bug to diagnose and <steps up on soapbox> one that could have been easily avoided by making member variables private! <steps down> thank you. :-)
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org