You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hc.apache.org by "Roland Weber (JIRA)" <ji...@apache.org> on 2007/07/26 20:18:03 UTC

[jira] Created: (HTTPCLIENT-675) thread starving in MultiThreadedHttpConnectionManager

thread starving in MultiThreadedHttpConnectionManager
-----------------------------------------------------

                 Key: HTTPCLIENT-675
                 URL: https://issues.apache.org/jira/browse/HTTPCLIENT-675
             Project: HttpComponents HttpClient
          Issue Type: Bug
          Components: HttpConn
    Affects Versions: 3.1 RC1
            Reporter: Roland Weber
            Assignee: Roland Weber
             Fix For: 3.1 Final


Hi folks,

I might have found a bug in MTHCM. It has to do with removing HostConnectionPool instances that have no more connections in them. That was a fix for a memory leak we previously had. There are two cases where the pools get deleted. One is in handleLostConnection: (excerpt)
  ...
  if (hostPool.numConnections == 0) mapHosts.remove(config);
  notifyWaitingThread(config);
  ...

Could this delete a pool in which there is still a thread waiting to get a connection? If so, the thread would remain in the global pool. But even if it is interrupted there, it would still use the old HostConnectionPool in which no connection will ever become available again.

I suggest to change the removal check in both cases to:
  if ((hostPool.numConnections < 1) && hostPool.waitingThreads.isEmpty)

What do you think?

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


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


[jira] Updated: (HTTPCLIENT-675) thread starving in MultiThreadedHttpConnectionManager

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

Roland Weber updated HTTPCLIENT-675:
------------------------------------

    Attachment: 2k7-07-27-MTHCM-675.txt

please review

> thread starving in MultiThreadedHttpConnectionManager
> -----------------------------------------------------
>
>                 Key: HTTPCLIENT-675
>                 URL: https://issues.apache.org/jira/browse/HTTPCLIENT-675
>             Project: HttpComponents HttpClient
>          Issue Type: Bug
>          Components: HttpConn
>    Affects Versions: 3.1 RC1
>            Reporter: Roland Weber
>            Assignee: Roland Weber
>             Fix For: 3.1 Final
>
>         Attachments: 2k7-07-27-MTHCM-675.txt
>
>
> Hi folks,
> I might have found a bug in MTHCM. It has to do with removing HostConnectionPool instances that have no more connections in them. That was a fix for a memory leak we previously had. There are two cases where the pools get deleted. One is in handleLostConnection: (excerpt)
>   ...
>   if (hostPool.numConnections == 0) mapHosts.remove(config);
>   notifyWaitingThread(config);
>   ...
> Could this delete a pool in which there is still a thread waiting to get a connection? If so, the thread would remain in the global pool. But even if it is interrupted there, it would still use the old HostConnectionPool in which no connection will ever become available again.
> I suggest to change the removal check in both cases to:
>   if ((hostPool.numConnections < 1) && hostPool.waitingThreads.isEmpty)
> What do you think?

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


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


[jira] Commented: (HTTPCLIENT-675) thread starving in MultiThreadedHttpConnectionManager

Posted by "Roland Weber (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/HTTPCLIENT-675?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12519090 ] 

Roland Weber commented on HTTPCLIENT-675:
-----------------------------------------

If I hear no complaints, I'll commit this patch this week-end.


> thread starving in MultiThreadedHttpConnectionManager
> -----------------------------------------------------
>
>                 Key: HTTPCLIENT-675
>                 URL: https://issues.apache.org/jira/browse/HTTPCLIENT-675
>             Project: HttpComponents HttpClient
>          Issue Type: Bug
>          Components: HttpConn
>    Affects Versions: 3.1 RC1
>            Reporter: Roland Weber
>            Assignee: Roland Weber
>             Fix For: 3.1 Final
>
>         Attachments: 2k7-07-27-MTHCM-675.txt
>
>
> Hi folks,
> I might have found a bug in MTHCM. It has to do with removing HostConnectionPool instances that have no more connections in them. That was a fix for a memory leak we previously had. There are two cases where the pools get deleted. One is in handleLostConnection: (excerpt)
>   ...
>   if (hostPool.numConnections == 0) mapHosts.remove(config);
>   notifyWaitingThread(config);
>   ...
> Could this delete a pool in which there is still a thread waiting to get a connection? If so, the thread would remain in the global pool. But even if it is interrupted there, it would still use the old HostConnectionPool in which no connection will ever become available again.
> I suggest to change the removal check in both cases to:
>   if ((hostPool.numConnections < 1) && hostPool.waitingThreads.isEmpty)
> What do you think?

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


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


[jira] Resolved: (HTTPCLIENT-675) thread starving in MultiThreadedHttpConnectionManager

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

Roland Weber resolved HTTPCLIENT-675.
-------------------------------------

    Resolution: Fixed

> thread starving in MultiThreadedHttpConnectionManager
> -----------------------------------------------------
>
>                 Key: HTTPCLIENT-675
>                 URL: https://issues.apache.org/jira/browse/HTTPCLIENT-675
>             Project: HttpComponents HttpClient
>          Issue Type: Bug
>          Components: HttpConn
>    Affects Versions: 3.1 RC1
>            Reporter: Roland Weber
>            Assignee: Roland Weber
>             Fix For: 3.1 Final
>
>         Attachments: 2k7-07-27-MTHCM-675.txt
>
>
> Hi folks,
> I might have found a bug in MTHCM. It has to do with removing HostConnectionPool instances that have no more connections in them. That was a fix for a memory leak we previously had. There are two cases where the pools get deleted. One is in handleLostConnection: (excerpt)
>   ...
>   if (hostPool.numConnections == 0) mapHosts.remove(config);
>   notifyWaitingThread(config);
>   ...
> Could this delete a pool in which there is still a thread waiting to get a connection? If so, the thread would remain in the global pool. But even if it is interrupted there, it would still use the old HostConnectionPool in which no connection will ever become available again.
> I suggest to change the removal check in both cases to:
>   if ((hostPool.numConnections < 1) && hostPool.waitingThreads.isEmpty)
> What do you think?

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


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