Details
-
Bug
-
Status: Resolved
-
Major
-
Resolution: Fixed
-
4.0 Final
-
None
Description
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