[
https://issues.apache.org/jira/browse/HTTPCORE-378?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13979732#comment-13979732
]
Oleg Kalnichevski commented on HTTPCORE-378:
--------------------------------------------
Dmitry
It should be a big problem to collect all expired connections and close them
out outside the pool lock. I am however very uncomfortable with the idea of
using a backgroud thread to do the latter.
Taking into account that HTTPCORE-377 and HTTPCLIENT-1497 have been resolved
what would you like us to do about this issue?
Oleg
> AbstractConnPool should perform expired entries clean up outside of lock
> ------------------------------------------------------------------------
>
> Key: HTTPCORE-378
> URL: https://issues.apache.org/jira/browse/HTTPCORE-378
> Project: HttpComponents HttpCore
> Issue Type: Bug
> Components: HttpCore
> Affects Versions: 4.3.2
> Reporter: Dmitry Potapov
> Priority: Trivial
>
> Currently expired entries are closed at
> AbstractConnPool.getPoolEntryBlocking:230. If connections have non-zero
> SO_LINGER enabled this will cause other threads to wait up to SO_LINGER
> seconds.
> Unfortunately same reentrant lock is already held by PoolEntryFuture.get(),
> so list of pool entries to be closed must be accumulated but some external
> queue and processed by additional thread.
> There is workaround for this issue for http-clients: apply patches from
> HTTPCORE-377 and HTTPCLIENT-1497 and set SocketConfig.setSoLinger(0).
> Since this issue has workaround, I suggest to consider this issue as very low
> priority one.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
