[
https://issues.apache.org/jira/browse/HTTPASYNC-68?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitry Potapov updated HTTPASYNC-68:
------------------------------------
Attachment: abort-connection-before-requesting.patch
Please, consider attached patch as solution for this issue.
DefaultClientExchangeHandlerImpl.abortConnection() does nothing if there is no
connection in managedConn, so it is safe to call it at start of
.requestConnection().
> DefaultClientExchangeHandlerImpl.requestConnection() must close current
> managed connection
> ------------------------------------------------------------------------------------------
>
> Key: HTTPASYNC-68
> URL: https://issues.apache.org/jira/browse/HTTPASYNC-68
> Project: HttpComponents HttpAsyncClient
> Issue Type: Bug
> Affects Versions: 4.0 Final
> Reporter: Dmitry Potapov
> Attachments: abort-connection-before-requesting.patch
>
>
> Consider the following scenario:
> 1. HttpAsyncClient.execute() creates DefaultClientExchangeHandlerImpl and
> calls DefaultClientExchangeHandlerImpl.start()
> 2. DefaultClientExchangeHandlerImpl.start() in turn calls .requestConnection()
> 3. .requestConnection() asks connection pool for connection
> 4. Connection pool creates new connection to target server and returns
> callback to the DefaultClientExchangeHandlerImpl
> 5. DefaultClientExchangeHandlerImpl stores connection to managedConn and
> sends request to server
> 6. Server sends TCP FIN
> 7. Client's AbstractIOReactor notices activity in socket channel and calls
> DefaultNHttpClientConnection.consumeInput()
> 8. DefaultNHttpClientConnection.consumeInput() detects eof on connection and
> calls DefaultClientExchangeHandlerImpl.inputTerminated()
> 9. DefaultClientExchangeHandlerImpl.inputTerminated() in turn calls
> DefaultClientExchangeHandlerImpl.requestConnection()
> 10. Connection pool creates another connection to server and returns it to
> DefaultClientExchangeHandlerImpl.
> 11. DefaultClientExchangeHandlerImpl stores newly allocated connection to
> managedConn and does nothing with its previous value. So previous connection
> left open and not returned to pool. If maxPerRoute is relatively small, all
> connections can be exhausted before gc will occur and requests will hang for
> indefinite time
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
