[jira] [Commented] (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:comment-tabpanel=15682877#comment-15682877 ] Sergiu Prodan commented on HTTPCORE-433: Oleg I've tried the patch you provided and it seems to fix the problem. Thank you! Sergiu > 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] [Commented] (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:comment-tabpanel=15679689#comment-15679689 ] Oleg Kalnichevski commented on HTTPCORE-433: Sergiu Could you please try out the patch [2] from this branch [1] and let me know if it solves the problem for you? Oleg [1] https://github.com/ok2c/httpcore/tree/HTTPCORE-433 [2] https://github.com/apache/httpcore/compare/4.4.x...ok2c:HTTPCORE-433 > 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] [Commented] (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:comment-tabpanel=15519152#comment-15519152 ] Sergiu Prodan commented on HTTPCORE-433: Please see my comment: https://github.com/ok2c/httpcore/commit/b1e6ec7b80efced8e315b722a734c178ab19697a#commitcomment-19158383 > 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 > > 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] [Commented] (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:comment-tabpanel=15518758#comment-15518758 ] Oleg Kalnichevski commented on HTTPCORE-433: Sergiu Could you please test the following patch and let me know if that fixes the problem for you? https://github.com/ok2c/httpcore/commit/b1e6ec7b80efced8e315b722a734c178ab19697a Oleg > 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 > > 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] [Commented] (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:comment-tabpanel=15509092#comment-15509092 ] Sergiu Prodan commented on HTTPCORE-433: Thanks for the reply! I'll give it a try in the next days > 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 > > 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
