You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hc.apache.org by "Scott Stanton (JIRA)" <ji...@apache.org> on 2012/10/03 03:12:07 UTC

[jira] [Created] (HTTPCORE-315) HttpAsyncRequester leaks a connection if a request is cancelled before the connection is established

Scott Stanton created HTTPCORE-315:
--------------------------------------

             Summary: HttpAsyncRequester leaks a connection if a request is cancelled before the connection is established
                 Key: HTTPCORE-315
                 URL: https://issues.apache.org/jira/browse/HTTPCORE-315
             Project: HttpComponents HttpCore
          Issue Type: Bug
          Components: HttpCore NIO
    Affects Versions: 4.2.2
            Reporter: Scott Stanton


When using HttpAsyncRequester in combination with a BasicNIOConnPool, if the future returned from execute() is cancelled before the connection is established, then the connection will be leaked after it connects (added to the leased list after the cancelled() callbacks are invoked).  The sequence that leads to this is:

* AbstractNIOConnPool.requestCompleted() calls RouteSpecificPool.completed() which ultimately calls HttpAsyncRequester.completed()
* HttpAsyncRequester.completed() detects that the requestFuture is done, so it attempts to release the pool entry
* The pool entry hasn't been added to the leased list yet, so the release has no effect and the connection is not added to the available list
* After the completed callback returns to requestCompleted(), the connection is added to the leased list.

At this point, no thread is expecting to do anything further with the connection, so it is effectively lost and consuming a pool slot.

I think the correct remedy is to ensure that the connection is added to the global leased list as well as the route specific leased list before the completed() callback is invoked.  This should ensure that the connection is properly cleaned up.



--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org


[jira] [Resolved] (HTTPCORE-315) HttpAsyncRequester leaks a connection if a request is cancelled before the connection is established

Posted by "Oleg Kalnichevski (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/HTTPCORE-315?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Oleg Kalnichevski resolved HTTPCORE-315.
----------------------------------------

       Resolution: Fixed
    Fix Version/s: 4.2.3

Hi Scott,
Many thanks for a detailed analysis of the problem and a quality patch. Patch committed to both SVN trunk and 4.2.x branch.

Oleg
                
> HttpAsyncRequester leaks a connection if a request is cancelled before the connection is established
> ----------------------------------------------------------------------------------------------------
>
>                 Key: HTTPCORE-315
>                 URL: https://issues.apache.org/jira/browse/HTTPCORE-315
>             Project: HttpComponents HttpCore
>          Issue Type: Bug
>          Components: HttpCore NIO
>    Affects Versions: 4.2.2
>            Reporter: Scott Stanton
>             Fix For: 4.2.3
>
>         Attachments: HTTPCORE-315.patch
>
>
> When using HttpAsyncRequester in combination with a BasicNIOConnPool, if the future returned from execute() is cancelled before the connection is established, then the connection will be leaked after it connects (added to the leased list after the cancelled() callbacks are invoked).  The sequence that leads to this is:
> * AbstractNIOConnPool.requestCompleted() calls RouteSpecificPool.completed() which ultimately calls HttpAsyncRequester.completed()
> * HttpAsyncRequester.completed() detects that the requestFuture is done, so it attempts to release the pool entry
> * The pool entry hasn't been added to the leased list yet, so the release has no effect and the connection is not added to the available list
> * After the completed callback returns to requestCompleted(), the connection is added to the leased list.
> At this point, no thread is expecting to do anything further with the connection, so it is effectively lost and consuming a pool slot.
> I think the correct remedy is to ensure that the connection is added to the global leased list as well as the route specific leased list before the completed() callback is invoked.  This should ensure that the connection is properly cleaned up.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org


[jira] [Updated] (HTTPCORE-315) HttpAsyncRequester leaks a connection if a request is cancelled before the connection is established

Posted by "Scott Stanton (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/HTTPCORE-315?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Scott Stanton updated HTTPCORE-315:
-----------------------------------

    Attachment: HTTPCORE-315.patch
    
> HttpAsyncRequester leaks a connection if a request is cancelled before the connection is established
> ----------------------------------------------------------------------------------------------------
>
>                 Key: HTTPCORE-315
>                 URL: https://issues.apache.org/jira/browse/HTTPCORE-315
>             Project: HttpComponents HttpCore
>          Issue Type: Bug
>          Components: HttpCore NIO
>    Affects Versions: 4.2.2
>            Reporter: Scott Stanton
>         Attachments: HTTPCORE-315.patch
>
>
> When using HttpAsyncRequester in combination with a BasicNIOConnPool, if the future returned from execute() is cancelled before the connection is established, then the connection will be leaked after it connects (added to the leased list after the cancelled() callbacks are invoked).  The sequence that leads to this is:
> * AbstractNIOConnPool.requestCompleted() calls RouteSpecificPool.completed() which ultimately calls HttpAsyncRequester.completed()
> * HttpAsyncRequester.completed() detects that the requestFuture is done, so it attempts to release the pool entry
> * The pool entry hasn't been added to the leased list yet, so the release has no effect and the connection is not added to the available list
> * After the completed callback returns to requestCompleted(), the connection is added to the leased list.
> At this point, no thread is expecting to do anything further with the connection, so it is effectively lost and consuming a pool slot.
> I think the correct remedy is to ensure that the connection is added to the global leased list as well as the route specific leased list before the completed() callback is invoked.  This should ensure that the connection is properly cleaned up.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org


[jira] [Commented] (HTTPCORE-315) HttpAsyncRequester leaks a connection if a request is cancelled before the connection is established

Posted by "Scott Stanton (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/HTTPCORE-315?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13468265#comment-13468265 ] 

Scott Stanton commented on HTTPCORE-315:
----------------------------------------

I have attached a possible fix for this issue.  Splitting the RouteSpecificPool.completed() call into createEntry() and completed() allows the requestCompleted() method to add the entry to the global leased list before calling completed().
                
> HttpAsyncRequester leaks a connection if a request is cancelled before the connection is established
> ----------------------------------------------------------------------------------------------------
>
>                 Key: HTTPCORE-315
>                 URL: https://issues.apache.org/jira/browse/HTTPCORE-315
>             Project: HttpComponents HttpCore
>          Issue Type: Bug
>          Components: HttpCore NIO
>    Affects Versions: 4.2.2
>            Reporter: Scott Stanton
>         Attachments: HTTPCORE-315.patch
>
>
> When using HttpAsyncRequester in combination with a BasicNIOConnPool, if the future returned from execute() is cancelled before the connection is established, then the connection will be leaked after it connects (added to the leased list after the cancelled() callbacks are invoked).  The sequence that leads to this is:
> * AbstractNIOConnPool.requestCompleted() calls RouteSpecificPool.completed() which ultimately calls HttpAsyncRequester.completed()
> * HttpAsyncRequester.completed() detects that the requestFuture is done, so it attempts to release the pool entry
> * The pool entry hasn't been added to the leased list yet, so the release has no effect and the connection is not added to the available list
> * After the completed callback returns to requestCompleted(), the connection is added to the leased list.
> At this point, no thread is expecting to do anything further with the connection, so it is effectively lost and consuming a pool slot.
> I think the correct remedy is to ensure that the connection is added to the global leased list as well as the route specific leased list before the completed() callback is invoked.  This should ensure that the connection is properly cleaned up.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org