Yes, it seems that this is my problem. I have two dumps which are 5m after each 
other. I have looked to AbstractNIOConnPool and I have in leasing requests 350

then I have one route only in routeToPool and there I have:

pending: 55
availble: 3
leased: 0

and these values are the same 5m after except the leasingRequests which are 
higher, but it seems that pending has not moved and the objects are the same. 
Even if I have configured SocketTimeout and Connection acquire timeout to 10s

When the request is removed from pending? 

Thank you
Tom

> On 29. 4. 2015, at 13:46, Oleg Kalnichevski <[email protected]> wrote:
> 
> 
> On Wed, Apr 29, 2015 at 1:02 PM, Tomas Tunkl <[email protected] 
> <mailto:[email protected]>> wrote:
>> My problem is that client has stopped sending requests, and I have noticed 
>> that leasingRequests are not getting empty. So I was thinking whether this 
>> could be my problem.
>> Thank you
>> Tom
> 
> 
> Lease request backlog get processed every time a connection gets released 
> back to the pool (there are other cases such as connect failure or timeout, 
> but connection release is the primary one). If lease requests get piling up 
> in the queue, that most likely means that the pool has been exhausted and 
> leased connections are not being released back to the pool.
> 
> Oleg
> 
> 
> 
>>> On 29. 4. 2015, at 12:41, Oleg Kalnichevski <[email protected]> wrote:
>>> On Wed, Apr 29, 2015 at 12:31 PM, Tomas Tunkl <[email protected]> wrote:
>>>> Hi,
>>>> I have noticed that. But:
>>>> processPendingRequests is called only by enumAvailable or enumLeased, 
>>>> which are called by closeExpired and closeIdle, these are called 
>>>> explicitly right?
>>>> processNextPendingRequest is called release(explicitly called), 
>>>> requestCancelled, requestFailed, requestTimeout and these are called in 
>>>> InternalSessionRequestCallback. By corresponding methods. But as I 
>>>> understand the problem to get to this some request has to be able to do:
>>>> final SessionRequest sessionRequest = this.ioreactor.connect(
>>>>        remoteAddress, localAddress, route, this.sessionRequestCallback);
>>>> Which doesnt have to happen. And in that case the requests are there 
>>>> forever. There is no automatic remove of requests from leasingRequests
>>>> Tom
>>> I am sorry but I am not sure I understand the problem you are having.
>>> Oleg
>>>>> On 29. 4. 2015, at 11:36, Oleg Kalnichevski <[email protected]> 
>>>>> wrote:
>>>>> On Tue, Apr 28, 2015 at 9:14 AM, Tomas Tunkl <[email protected]> 
>>>>> wrote:
>>>>>> Hi,
>>>>>> I have some problems with ApacheAsyncHttpClient. I have tracked the 
>>>>>> problems to one specific place I am interested in.
>>>>>> In AbstractNIOConnPool I can see that I have in leasingRequests 112 
>>>>>> entries. I have searched the code and couldnt find how the entries are 
>>>>>> processed. I believe that request gets to leasingRequests when it cannot 
>>>>>> get connection, because all are used. But when the requests gets another 
>>>>>> chance? It seems to me, that it is stuck there forever.
>>>>> Leasing requests are processed by #processNextPendingRequest and 
>>>>> #processPendingRequests methods.
>>>>> Oleg
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: [email protected]
>>>>> For additional commands, e-mail: [email protected]
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: [email protected]
>>>> For additional commands, e-mail: [email protected]
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [email protected]
>>> For additional commands, e-mail: [email protected]
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [email protected] 
>> <mailto:[email protected]>
>> For additional commands, e-mail: [email protected] 
>> <mailto:[email protected]>
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected] 
> <mailto:[email protected]>
> For additional commands, e-mail: [email protected] 
> <mailto:[email protected]>

Reply via email to