hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sergiu Prodan (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (HTTPCORE-433) Setting validateAfterInactivity to 1ms increases lock contention in AbstractConnPool
Date Mon, 19 Sep 2016 14:56:20 GMT

     [ 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. This httpclient is used only for one route

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

  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.
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


> 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. This httpclient is used only for one route
> 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



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

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


Mime
View raw message