[jira] [Updated] (HTTPCORE-433) Setting validateAfterInactivity to 1ms increases lock contention in AbstractConnPool
[ https://issues.apache.org/jira/browse/HTTPCORE-433?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Oleg Kalnichevski updated HTTPCORE-433: --- Fix Version/s: (was: 5.0) 5.0-alpha2 4.4.6 > 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 > Fix For: 4.4.6, 5.0-alpha2 > > 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 > 0x000706e8b9a8 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
[jira] [Updated] (HTTPCORE-433) Setting validateAfterInactivity to 1ms increases lock contention in AbstractConnPool
[ https://issues.apache.org/jira/browse/HTTPCORE-433?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Oleg Kalnichevski updated HTTPCORE-433: --- Fix Version/s: (was: 4.4.6) 5.0 > 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 > Fix For: 5.0 > > 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 > 0x000706e8b9a8 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
[jira] [Updated] (HTTPCORE-433) Setting validateAfterInactivity to 1ms increases lock contention in AbstractConnPool
[ 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 0x000706e8b9a8 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. 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 0x000706e8b9a8 and is owned by Thread-4. The httpclient used in this test app is used from 10 threads and has the following settings: clientConnManager.setMaxTotal(100); clientConnManager.setDefaultMaxPerRoute(100); > 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 > 0x000706e8b9a8 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
[jira] [Updated] (HTTPCORE-433) Setting validateAfterInactivity to 1ms increases lock contention in AbstractConnPool
[ 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 0x000706e8b9a8 and is owned by Thread-4. The httpclient used in this test app is used from 10 threads and has the following settings: clientConnManager.setMaxTotal(100); clientConnManager.setDefaultMaxPerRoute(100); 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. 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 0x000706e8b9a8 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 > 0x000706e8b9a8 and is owned by Thread-4. The httpclient used in this test > app is used from 10 threads and has the following settings: > clientConnManager.setMaxTotal(100); > clientConnManager.setDefaultMaxPerRoute(100); -- 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
[jira] [Updated] (HTTPCORE-433) Setting validateAfterInactivity to 1ms increases lock contention in AbstractConnPool
[ 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 0x000706e8b9a8 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 0x000706e8b9a8 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 > 0x000706e8b9a8 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
[jira] [Updated] (HTTPCORE-433) Setting validateAfterInactivity to 1ms increases lock contention in AbstractConnPool
[ 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 0x000706e8b9a8 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. 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 0x000706e8b9a8 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 > 0x000706e8b9a8 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
[jira] [Updated] (HTTPCORE-433) Setting validateAfterInactivity to 1ms increases lock contention in AbstractConnPool
[ 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 0x000706e8b9a8 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 0x000706e8b9a8 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 > 0x000706e8b9a8 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
[jira] [Updated] (HTTPCORE-433) Setting validateAfterInactivity to 1ms increases lock contention in AbstractConnPool
[ https://issues.apache.org/jira/browse/HTTPCORE-433?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergiu Prodan updated HTTPCORE-433: --- Attachment: threads_when_inactivity_set_to_2000.png > 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. > 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 > 0x000706e8b9a8 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
[jira] [Updated] (HTTPCORE-433) Setting validateAfterInactivity to 1ms increases lock contention in AbstractConnPool
[ https://issues.apache.org/jira/browse/HTTPCORE-433?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergiu Prodan updated HTTPCORE-433: --- Attachment: threads_when_inactivity_set_to_1.png Thread visualisation when making requests from 10 different threads. PoolingHttpClientConnectionManager#setValidateAfterInactivity set to 1 > 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 > > > 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 > 0x000706e8b9a8 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
[jira] [Updated] (HTTPCORE-433) Setting validateAfterInactivity to 1ms increases lock contention in AbstractConnPool
[ https://issues.apache.org/jira/browse/HTTPCORE-433?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergiu Prodan updated HTTPCORE-433: --- Attachment: httpclient_thread_dump > 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 > > > 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 > 0x000706e8b9a8 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
[jira] [Updated] (HTTPCORE-433) Setting validateAfterInactivity to 1ms increases lock contention in AbstractConnPool
[ 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. 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 0x000706e8b9a8 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 0x000706e8b9a8 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 > > > 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 > 0x000706e8b9a8 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
