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

Sergiu Prodan updated HTTPCORE-433:
-----------------------------------
    Description: 
This issue was observed after upgrading to httpclient v4.5.2 and httpcore 
v4.4.4. 

When configuring the PoolingHttpClientConnectionManager, I have set 
validateAfterInactivity to 1ms as this is the only way of maintaining the old 
behaviour, i.e. checking every connection if is stale before using it.

I have observed a performance degradation under high load when the httpclient 
is shared between multiple threads. 

After taking a thread dump, one thing that got my attention was several threads 
waiting for same ReentrantLock instance while trying to 
AbstractConnPool#getPoolEntryBlocking/AbstractConnPool#release. The 
ReentrantLock instance in question was owned by another thread performing 
CPool#validate. Note that I use this httpclient to make calls to the same route.

It seems to me that performing this stale check inside the region protected by 
this lock is unnecessary and also induces a big performance hit when using the 
httpclient from multiple threads.

I've atached a thread dump of a test application that reproduces this 
behaviour. ReentrantLock in question in this thread dump is 0x0000000706e8b9a8 
and is owned by Thread-4

  was:
This issue was observed after upgrading to httpclient v4.5.2 and httpcore 
v4.4.4. 

When configuring the PoolingHttpClientConnectionManager, I have set 
validateAfterInactivity to 1ms as this is the only way of maintaining the old 
behaviour, i.e. checking every connection if is stale before using it.

I have observed a performance degradation under high load when the httpclient 
is shared between multiple threads. 

After taking a thread dump, one thing that got my attention was several threads 
waiting for same ReentrantLock instance while trying to 
AbstractConnPool#getPoolEntryBlocking/AbstractConnPool#release. The 
ReentrantLock instance in question was owned by another thread performing 
CPool#validate.

It seems to me that performing this stale check inside the region protected by 
this lock is unnecessary and also induces a big performance hit when using the 
httpclient from multiple threads.

I've atached a thread dump of a test application that reproduces this 
behaviour. ReentrantLock in question in this thread dump is 0x0000000706e8b9a8 
and is owned by Thread-4


> Setting validateAfterInactivity to 1ms increases lock contention in 
> AbstractConnPool
> ------------------------------------------------------------------------------------
>
>                 Key: HTTPCORE-433
>                 URL: https://issues.apache.org/jira/browse/HTTPCORE-433
>             Project: HttpComponents HttpCore
>          Issue Type: Bug
>          Components: HttpCore
>    Affects Versions: 4.4.4
>            Reporter: Sergiu Prodan
>         Attachments: httpclient_thread_dump, 
> threads_when_inactivity_set_to_1.png, threads_when_inactivity_set_to_2000.png
>
>
> This issue was observed after upgrading to httpclient v4.5.2 and httpcore 
> v4.4.4. 
> When configuring the PoolingHttpClientConnectionManager, I have set 
> validateAfterInactivity to 1ms as this is the only way of maintaining the old 
> behaviour, i.e. checking every connection if is stale before using it.
> I have observed a performance degradation under high load when the httpclient 
> is shared between multiple threads. 
> After taking a thread dump, one thing that got my attention was several 
> threads waiting for same ReentrantLock instance while trying to 
> AbstractConnPool#getPoolEntryBlocking/AbstractConnPool#release. The 
> ReentrantLock instance in question was owned by another thread performing 
> CPool#validate. Note that I use this httpclient to make calls to the same 
> route.
> It seems to me that performing this stale check inside the region protected 
> by this lock is unnecessary and also induces a big performance hit when using 
> the httpclient from multiple threads.
> I've atached a thread dump of a test application that reproduces this 
> behaviour. ReentrantLock in question in this thread dump is 
> 0x0000000706e8b9a8 and is owned by Thread-4



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org

Reply via email to