[jira] Created: (HTTPCLIENT-814) MultiThreadedHttpConnectionManager deadlocks when reusing socket connections

MultiThreadedHttpConnectionManager deadlocks when reusing socket connections
----------------------------------------------------------------------------

                 Key: HTTPCLIENT-814
                 URL: https://issues.apache.org/jira/browse/HTTPCLIENT-814
             Project: HttpComponents HttpClient
          Issue Type: Bug
          Components: HttpClient
    Affects Versions: 3.1 Final
         Environment: Tomcat 6.18 running on a Windows 2003 server
            Reporter: Will Franco
             Fix For: 3.1.1


During our Load Testing we encountered that the MultiThreadedHttpConnectionManager deadlocks when reusing socket connections.   These socket connections remain in the pool in a CLOSE_WAIT state, and the pool is unable to reuse them or create new ones because the maximum number of connection has already been reached, thus deadlocking.

Let me explain briefly how this library is being used and the temporary work around that we are using.  However, the correct solution would be to use the connection pool.

Usage:
1) The HttPClient is being used to handle connections to another server from our Web Application.  So far, for every request our Web Apps processes we have to make at least one request to another server using the HttpClient.
2) Our load tester, loads our web app with thousands of request within the first 30 seconds, and maintains such high volume of requests for at least 24 hours

Work Around:
The current work around we implemented is to have different instances of the HttpClient per request, and we shutdown the Connection Manager once we complete the transaction with the other server.

The next work around we will be implementing is to called the closeIdleConnections, this solution will remove the connections that can pontentialy deadlock the connection manager allowing it to allocate new ones.

Please email me to willfranco@... if you need any further information regarding this issue.


Please email me at willfranco@... if you need further information.


--
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: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

     [ https://issues.apache.org/jira/browse/HTTPCLIENT-814?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Will Franco updated HTTPCLIENT-814:
-----------------------------------

    Description:
During our Load Testing we encountered that the MultiThreadedHttpConnectionManager deadlocks when reusing socket connections.   These socket connections remain in the pool in a CLOSE_WAIT state, and the pool is unable to reuse them or create new ones because the maximum number of connection has already been reached, thus deadlocking.

Let me explain briefly how this library is being used and the temporary work around that we are using.  However, the correct solution would be to use the connection pool.

Usage:
1) The HttPClient is being used to handle connections to another server from our Web Application.  So far, for every request our Web Apps processes we have to make at least one request to another server using the HttpClient.
2) Our load tester, loads our web app with thousands of request within the first 30 seconds, and maintains such high volume of requests for at least 24 hours

Work Around:
The current work around we implemented is to have different instances of the HttpClient per request, and we shutdown the Connection Manager once we complete the transaction with the other server.

The next work around we will be implementing is to called the closeIdleConnections, this solution will remove the connections that can pontentialy deadlock the connection manager allowing it to allocate new ones.

Please email me to willfranco@... if you need any further information regarding this issue.

  was:
During our Load Testing we encountered that the MultiThreadedHttpConnectionManager deadlocks when reusing socket connections.   These socket connections remain in the pool in a CLOSE_WAIT state, and the pool is unable to reuse them or create new ones because the maximum number of connection has already been reached, thus deadlocking.

Let me explain briefly how this library is being used and the temporary work around that we are using.  However, the correct solution would be to use the connection pool.

Usage:
1) The HttPClient is being used to handle connections to another server from our Web Application.  So far, for every request our Web Apps processes we have to make at least one request to another server using the HttpClient.
2) Our load tester, loads our web app with thousands of request within the first 30 seconds, and maintains such high volume of requests for at least 24 hours

Work Around:
The current work around we implemented is to have different instances of the HttpClient per request, and we shutdown the Connection Manager once we complete the transaction with the other server.

The next work around we will be implementing is to called the closeIdleConnections, this solution will remove the connections that can pontentialy deadlock the connection manager allowing it to allocate new ones.

Please email me to willfranco@... if you need any further information regarding this issue.


Please email me at willfranco@... if you need further information.

> MultiThreadedHttpConnectionManager deadlocks when reusing socket connections
> ----------------------------------------------------------------------------
>
>                 Key: HTTPCLIENT-814
>                 URL: https://issues.apache.org/jira/browse/HTTPCLIENT-814
>             Project: HttpComponents HttpClient
>          Issue Type: Bug
>          Components: HttpClient
>    Affects Versions: 3.1 Final
>         Environment: Tomcat 6.18 running on a Windows 2003 server
>            Reporter: Will Franco
>             Fix For: 3.1.1
>
>
> During our Load Testing we encountered that the MultiThreadedHttpConnectionManager deadlocks when reusing socket connections.   These socket connections remain in the pool in a CLOSE_WAIT state, and the pool is unable to reuse them or create new ones because the maximum number of connection has already been reached, thus deadlocking.
> Let me explain briefly how this library is being used and the temporary work around that we are using.  However, the correct solution would be to use the connection pool.
> Usage:
> 1) The HttPClient is being used to handle connections to another server from our Web Application.  So far, for every request our Web Apps processes we have to make at least one request to another server using the HttpClient.
> 2) Our load tester, loads our web app with thousands of request within the first 30 seconds, and maintains such high volume of requests for at least 24 hours
> Work Around:
> The current work around we implemented is to have different instances of the HttpClient per request, and we shutdown the Connection Manager once we complete the transaction with the other server.
> The next work around we will be implementing is to called the closeIdleConnections, this solution will remove the connections that can pontentialy deadlock the connection manager allowing it to allocate new ones.
> Please email me to willfranco@... if you need any further information regarding this issue.

--
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: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

    [ https://issues.apache.org/jira/browse/HTTPCLIENT-814?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12662398#action_12662398 ]

Oleg Kalnichevski commented on HTTPCLIENT-814:
----------------------------------------------

I suspect rather strongly your application is leaking connections by not returning them back to the pool. Connections are not supposed just to pile up, unless your application is always connecting to a new host or not releasing existing connections back to the pool.

BTW, consider upgrading to 4.0 which has a massively better connection management architecture.

Oleg

> MultiThreadedHttpConnectionManager deadlocks when reusing socket connections
> ----------------------------------------------------------------------------
>
>                 Key: HTTPCLIENT-814
>                 URL: https://issues.apache.org/jira/browse/HTTPCLIENT-814
>             Project: HttpComponents HttpClient
>          Issue Type: Bug
>          Components: HttpClient
>    Affects Versions: 3.1 Final
>         Environment: Tomcat 6.18 running on a Windows 2003 server
>            Reporter: Will Franco
>             Fix For: 3.1.1
>
>
> During our Load Testing we encountered that the MultiThreadedHttpConnectionManager deadlocks when reusing socket connections.   These socket connections remain in the pool in a CLOSE_WAIT state, and the pool is unable to reuse them or create new ones because the maximum number of connection has already been reached, thus deadlocking.
> Let me explain briefly how this library is being used and the temporary work around that we are using.  However, the correct solution would be to use the connection pool.
> Usage:
> 1) The HttPClient is being used to handle connections to another server from our Web Application.  So far, for every request our Web Apps processes we have to make at least one request to another server using the HttpClient.
> 2) Our load tester, loads our web app with thousands of request within the first 30 seconds, and maintains such high volume of requests for at least 24 hours
> Work Around:
> The current work around we implemented is to have different instances of the HttpClient per request, and we shutdown the Connection Manager once we complete the transaction with the other server.
> The next work around we will be implementing is to called the closeIdleConnections, this solution will remove the connections that can pontentialy deadlock the connection manager allowing it to allocate new ones.
> Please email me to willfranco@... if you need any further information regarding this issue.

--
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: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

     [ https://issues.apache.org/jira/browse/HTTPCLIENT-814?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Will Franco updated HTTPCLIENT-814:
-----------------------------------

    Description:
During our Load Testing we encountered that the MultiThreadedHttpConnectionManager deadlocks when reusing socket connections.   These socket connections remain in the pool in a CLOSE_WAIT state, and the pool is unable to reuse them or create new ones because the maximum number of connection has already been reached, thus deadlocking.

Let me explain briefly how this library is being used and the temporary work around that we are using.  However, the correct solution would be to use the connection pool.

Usage:
1) The HttPClient is being used to handle connections to another server from our Web Application.  So far, for every request our Web Apps processes we have to make at least one request to another server using the HttpClient.
2) Our load tester, loads our web app with thousands of requests within the first 30 seconds, and maintains such high volume of requests for at least 24 hours

Work Around:
The current work around we implemented is to have different HttpClient instances per request, and we shutdown the Connection Manager once we complete the transaction with the other server.

The next work around we will be trying is to call the closeIdleConnections, this solution will remove the connections that can potentially deadlock the connection manager allowing it to allocate new ones.

Please email me to willfranco@... if you need any further information regarding this issue.


  was:
During our Load Testing we encountered that the MultiThreadedHttpConnectionManager deadlocks when reusing socket connections.   These socket connections remain in the pool in a CLOSE_WAIT state, and the pool is unable to reuse them or create new ones because the maximum number of connection has already been reached, thus deadlocking.

Let me explain briefly how this library is being used and the temporary work around that we are using.  However, the correct solution would be to use the connection pool.

Usage:
1) The HttPClient is being used to handle connections to another server from our Web Application.  So far, for every request our Web Apps processes we have to make at least one request to another server using the HttpClient.
2) Our load tester, loads our web app with thousands of request within the first 30 seconds, and maintains such high volume of requests for at least 24 hours

Work Around:
The current work around we implemented is to have different instances of the HttpClient per request, and we shutdown the Connection Manager once we complete the transaction with the other server.

The next work around we will be implementing is to called the closeIdleConnections, this solution will remove the connections that can pontentialy deadlock the connection manager allowing it to allocate new ones.

Please email me to willfranco@... if you need any further information regarding this issue.

> MultiThreadedHttpConnectionManager deadlocks when reusing socket connections
> ----------------------------------------------------------------------------
>
>                 Key: HTTPCLIENT-814
>                 URL: https://issues.apache.org/jira/browse/HTTPCLIENT-814
>             Project: HttpComponents HttpClient
>          Issue Type: Bug
>          Components: HttpClient
>    Affects Versions: 3.1 Final
>         Environment: Tomcat 6.18 running on a Windows 2003 server
>            Reporter: Will Franco
>             Fix For: 3.1.1
>
>
> During our Load Testing we encountered that the MultiThreadedHttpConnectionManager deadlocks when reusing socket connections.   These socket connections remain in the pool in a CLOSE_WAIT state, and the pool is unable to reuse them or create new ones because the maximum number of connection has already been reached, thus deadlocking.
> Let me explain briefly how this library is being used and the temporary work around that we are using.  However, the correct solution would be to use the connection pool.
> Usage:
> 1) The HttPClient is being used to handle connections to another server from our Web Application.  So far, for every request our Web Apps processes we have to make at least one request to another server using the HttpClient.
> 2) Our load tester, loads our web app with thousands of requests within the first 30 seconds, and maintains such high volume of requests for at least 24 hours
> Work Around:
> The current work around we implemented is to have different HttpClient instances per request, and we shutdown the Connection Manager once we complete the transaction with the other server.
> The next work around we will be trying is to call the closeIdleConnections, this solution will remove the connections that can potentially deadlock the connection manager allowing it to allocate new ones.
> Please email me to willfranco@... if you need any further information regarding this issue.

--
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: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

     [ https://issues.apache.org/jira/browse/HTTPCLIENT-814?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Will Franco updated HTTPCLIENT-814:
-----------------------------------

    Description:
During our Load Testing we encountered that the MultiThreadedHttpConnectionManager deadlocks when reusing socket connections.   These socket connections remain in the pool in a CLOSE_WAIT state, and the pool is unable to reuse them or create new ones because the maximum number of connection has already been reached, thus deadlocking.

Let me explain briefly how this library is being used and the temporary work around that we are using.  However, the correct solution would be to use the connection pool.

Usage:
1) The HttPClient is being used to handle connections to another server from our Web Application.  So far, for every request our Web App processes we have to make at least one request to another server using the HttpClient.
2) Our load tester, loads our web app with thousands of requests within the first 30 seconds, and maintains such high volume of requests for at least 24 hours

Work Around:
The current work around we implemented is to have different HttpClient instances per request, and we shutdown the Connection Manager once we complete the transaction with the other server.

The next work around we will be trying is to call the closeIdleConnections, this solution will remove the connections that can potentially deadlock the connection manager allowing it to allocate new ones.

Please email me to willfranco@... if you need any further information regarding this issue.


  was:
During our Load Testing we encountered that the MultiThreadedHttpConnectionManager deadlocks when reusing socket connections.   These socket connections remain in the pool in a CLOSE_WAIT state, and the pool is unable to reuse them or create new ones because the maximum number of connection has already been reached, thus deadlocking.

Let me explain briefly how this library is being used and the temporary work around that we are using.  However, the correct solution would be to use the connection pool.

Usage:
1) The HttPClient is being used to handle connections to another server from our Web Application.  So far, for every request our Web Apps processes we have to make at least one request to another server using the HttpClient.
2) Our load tester, loads our web app with thousands of requests within the first 30 seconds, and maintains such high volume of requests for at least 24 hours

Work Around:
The current work around we implemented is to have different HttpClient instances per request, and we shutdown the Connection Manager once we complete the transaction with the other server.

The next work around we will be trying is to call the closeIdleConnections, this solution will remove the connections that can potentially deadlock the connection manager allowing it to allocate new ones.

Please email me to willfranco@... if you need any further information regarding this issue.

> MultiThreadedHttpConnectionManager deadlocks when reusing socket connections
> ----------------------------------------------------------------------------
>
>                 Key: HTTPCLIENT-814
>                 URL: https://issues.apache.org/jira/browse/HTTPCLIENT-814
>             Project: HttpComponents HttpClient
>          Issue Type: Bug
>          Components: HttpClient
>    Affects Versions: 3.1 Final
>         Environment: Tomcat 6.18 running on a Windows 2003 server
>            Reporter: Will Franco
>             Fix For: Future
>
>
> During our Load Testing we encountered that the MultiThreadedHttpConnectionManager deadlocks when reusing socket connections.   These socket connections remain in the pool in a CLOSE_WAIT state, and the pool is unable to reuse them or create new ones because the maximum number of connection has already been reached, thus deadlocking.
> Let me explain briefly how this library is being used and the temporary work around that we are using.  However, the correct solution would be to use the connection pool.
> Usage:
> 1) The HttPClient is being used to handle connections to another server from our Web Application.  So far, for every request our Web App processes we have to make at least one request to another server using the HttpClient.
> 2) Our load tester, loads our web app with thousands of requests within the first 30 seconds, and maintains such high volume of requests for at least 24 hours
> Work Around:
> The current work around we implemented is to have different HttpClient instances per request, and we shutdown the Connection Manager once we complete the transaction with the other server.
> The next work around we will be trying is to call the closeIdleConnections, this solution will remove the connections that can potentially deadlock the connection manager allowing it to allocate new ones.
> Please email me to willfranco@... if you need any further information regarding this issue.

--
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: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

     [ https://issues.apache.org/jira/browse/HTTPCLIENT-814?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Will Franco updated HTTPCLIENT-814:
-----------------------------------

    Fix Version/s:     (was: 3.1.1)
                   Future

> MultiThreadedHttpConnectionManager deadlocks when reusing socket connections
> ----------------------------------------------------------------------------
>
>                 Key: HTTPCLIENT-814
>                 URL: https://issues.apache.org/jira/browse/HTTPCLIENT-814
>             Project: HttpComponents HttpClient
>          Issue Type: Bug
>          Components: HttpClient
>    Affects Versions: 3.1 Final
>         Environment: Tomcat 6.18 running on a Windows 2003 server
>            Reporter: Will Franco
>             Fix For: Future
>
>
> During our Load Testing we encountered that the MultiThreadedHttpConnectionManager deadlocks when reusing socket connections.   These socket connections remain in the pool in a CLOSE_WAIT state, and the pool is unable to reuse them or create new ones because the maximum number of connection has already been reached, thus deadlocking.
> Let me explain briefly how this library is being used and the temporary work around that we are using.  However, the correct solution would be to use the connection pool.
> Usage:
> 1) The HttPClient is being used to handle connections to another server from our Web Application.  So far, for every request our Web App processes we have to make at least one request to another server using the HttpClient.
> 2) Our load tester, loads our web app with thousands of requests within the first 30 seconds, and maintains such high volume of requests for at least 24 hours
> Work Around:
> The current work around we implemented is to have different HttpClient instances per request, and we shutdown the Connection Manager once we complete the transaction with the other server.
> The next work around we will be trying is to call the closeIdleConnections, this solution will remove the connections that can potentially deadlock the connection manager allowing it to allocate new ones.
> Please email me to willfranco@... if you need any further information regarding this issue.

--
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: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

     [ https://issues.apache.org/jira/browse/HTTPCLIENT-814?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Oleg Kalnichevski resolved HTTPCLIENT-814.
------------------------------------------

    Resolution: Invalid

I see no evidence of this being a bug in HttpClient. Feel free to reopen the issue if you have more details about the problem.

Oleg

> MultiThreadedHttpConnectionManager deadlocks when reusing socket connections
> ----------------------------------------------------------------------------
>
>                 Key: HTTPCLIENT-814
>                 URL: https://issues.apache.org/jira/browse/HTTPCLIENT-814
>             Project: HttpComponents HttpClient
>          Issue Type: Bug
>          Components: HttpClient
>    Affects Versions: 3.1 Final
>         Environment: Tomcat 6.18 running on a Windows 2003 server
>            Reporter: Will Franco
>             Fix For: Future
>
>
> During our Load Testing we encountered that the MultiThreadedHttpConnectionManager deadlocks when reusing socket connections.   These socket connections remain in the pool in a CLOSE_WAIT state, and the pool is unable to reuse them or create new ones because the maximum number of connection has already been reached, thus deadlocking.
> Let me explain briefly how this library is being used and the temporary work around that we are using.  However, the correct solution would be to use the connection pool.
> Usage:
> 1) The HttPClient is being used to handle connections to another server from our Web Application.  So far, for every request our Web App processes we have to make at least one request to another server using the HttpClient.
> 2) Our load tester, loads our web app with thousands of requests within the first 30 seconds, and maintains such high volume of requests for at least 24 hours
> Work Around:
> The current work around we implemented is to have different HttpClient instances per request, and we shutdown the Connection Manager once we complete the transaction with the other server.
> The next work around we will be trying is to call the closeIdleConnections, this solution will remove the connections that can potentially deadlock the connection manager allowing it to allocate new ones.
> Please email me to willfranco@... if you need any further information regarding this issue.

--
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: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

    [ https://issues.apache.org/jira/browse/HTTPCLIENT-814?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12753325#action_12753325 ]

hector rovira commented on HTTPCLIENT-814:
------------------------------------------

I have been able to reproduce this bug.  This is also an issue for me.  Timeouts don't seem to be having an effect.  I would upgrade to 4.0, but can't right now.  

Here's the snippet of code where I'm accessing the HttpClient (v.3.1).  (Pls ignore ResponseCallback and my custom exceptions).  It blocks on the httpClient.executeMethod.  Setting log4j.xml to debug showed that the org.apache.commons.httpclient.MultiThreadedHttpConnectionManager "Unable to get a connection, waiting..."

    public Object executeMethod(HttpMethod method, ResponseCallback responseCallback) throws HttpClientException, HttpClientResponseException {
            try {
                int statusCode = httpClient.executeMethod(method);
                log.info("executeMethod(" + method.getPath() + "):" + statusCode);
                return responseCallback.onResponse(statusCode, method);
            } catch (IOException e) {
                throw new HttpClientException(method, e);
            } finally {
                method.releaseConnection();
            }
    }

My workaround is to use the org.apache.commons.httpclient.SimpleHttpConnectionManager instead, and add a synchronization block to avoid multiple threads using the httpclient at the same time.

> MultiThreadedHttpConnectionManager deadlocks when reusing socket connections
> ----------------------------------------------------------------------------
>
>                 Key: HTTPCLIENT-814
>                 URL: https://issues.apache.org/jira/browse/HTTPCLIENT-814
>             Project: HttpComponents HttpClient
>          Issue Type: Bug
>          Components: HttpClient
>    Affects Versions: 3.1 Final
>         Environment: Tomcat 6.18 running on a Windows 2003 server
>            Reporter: Will Franco
>             Fix For: Future
>
>
> During our Load Testing we encountered that the MultiThreadedHttpConnectionManager deadlocks when reusing socket connections.   These socket connections remain in the pool in a CLOSE_WAIT state, and the pool is unable to reuse them or create new ones because the maximum number of connection has already been reached, thus deadlocking.
> Let me explain briefly how this library is being used and the temporary work around that we are using.  However, the correct solution would be to use the connection pool.
> Usage:
> 1) The HttPClient is being used to handle connections to another server from our Web Application.  So far, for every request our Web App processes we have to make at least one request to another server using the HttpClient.
> 2) Our load tester, loads our web app with thousands of requests within the first 30 seconds, and maintains such high volume of requests for at least 24 hours
> Work Around:
> The current work around we implemented is to have different HttpClient instances per request, and we shutdown the Connection Manager once we complete the transaction with the other server.
> The next work around we will be trying is to call the closeIdleConnections, this solution will remove the connections that can potentially deadlock the connection manager allowing it to allocate new ones.
> Please email me to willfranco@... if you need any further information regarding this issue.

--
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: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

    [ https://issues.apache.org/jira/browse/HTTPCLIENT-814?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12753488#action_12753488 ]

Oleg Kalnichevski commented on HTTPCLIENT-814:
----------------------------------------------

There has been only one confirmed case of HttpClient leaking connections [1]. The bug affects tunneled (proxied) SSL connections only. This bug has been fixed in the 3.x branch [2], but the fix has never been released with an official release. You can get the latest code snapshot from the SVN repository, build it and see if that fixes the issue for you. Please note there will be NO new releases off the 3.x branch. Users are strongly advised to upgrade to 4.0

Oleg

[1] https://issues.apache.org/jira/browse/HTTPCLIENT-848
[2] http://svn.apache.org/repos/asf/httpcomponents/oac.hc3x/trunk/

> MultiThreadedHttpConnectionManager deadlocks when reusing socket connections
> ----------------------------------------------------------------------------
>
>                 Key: HTTPCLIENT-814
>                 URL: https://issues.apache.org/jira/browse/HTTPCLIENT-814
>             Project: HttpComponents HttpClient
>          Issue Type: Bug
>          Components: HttpClient
>    Affects Versions: 3.1 Final
>         Environment: Tomcat 6.18 running on a Windows 2003 server
>            Reporter: Will Franco
>             Fix For: Future
>
>
> During our Load Testing we encountered that the MultiThreadedHttpConnectionManager deadlocks when reusing socket connections.   These socket connections remain in the pool in a CLOSE_WAIT state, and the pool is unable to reuse them or create new ones because the maximum number of connection has already been reached, thus deadlocking.
> Let me explain briefly how this library is being used and the temporary work around that we are using.  However, the correct solution would be to use the connection pool.
> Usage:
> 1) The HttPClient is being used to handle connections to another server from our Web Application.  So far, for every request our Web App processes we have to make at least one request to another server using the HttpClient.
> 2) Our load tester, loads our web app with thousands of requests within the first 30 seconds, and maintains such high volume of requests for at least 24 hours
> Work Around:
> The current work around we implemented is to have different HttpClient instances per request, and we shutdown the Connection Manager once we complete the transaction with the other server.
> The next work around we will be trying is to call the closeIdleConnections, this solution will remove the connections that can potentially deadlock the connection manager allowing it to allocate new ones.
> Please email me to willfranco@... if you need any further information regarding this issue.

--
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: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...