[
https://issues.apache.org/jira/browse/HTTPCLIENT-948?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12875134#action_12875134
]
Oleg Kalnichevski commented on HTTPCLIENT-948:
----------------------------------------------
> I just tried navigating through the classes to get a feel for what's
> involved, and man... is that code super complex!
Roland, who pretty much devised the entire connection management API, had a
tendency to over-design and over-complicate things. He also seems to have
treated thread-safety as an afterthought and never got around to finishing his
work. On a number of occasions I felt like deprecating all connection pooling
classes and starting over.
> Can the HttpConnection escape into user-code anywhere?
I do not think so. The real connections always get wrapped with an 'adaptor'
class to ensure that the user can not mess with the real connection once it has
been released back to the pool. The user code always gets hold of an adaptor
instead of the real thing. The IdleConnectionHandler probably was the only
exception to that rule I can think of.
> I think the best option is to do 1) & 2). 1) makes getFreeEntry a lot safer,
> and 2) is a very straightforward approach. 3) seems like a lot of overhead.
I also think (1) and (2) seem the way to go. At the same time I would like to
invest a few cycles into evaluation a possibility of merging the functionality
of IdleConnectionHandler into BasicPoolEntry.
Oleg
> IdleConnectionHandler can leave closed connections in a inconsistent state
> --------------------------------------------------------------------------
>
> Key: HTTPCLIENT-948
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-948
> Project: HttpComponents HttpClient
> Issue Type: Bug
> Components: HttpConn
> Affects Versions: 4.0.1, 4.1 Alpha2
> Reporter: Oleg Kalnichevski
> Fix For: 4.1 Alpha3
>
>
> IdleConnectionHandler when shutting down 'stale' connection does not update
> the state of AbstractPoolEntry thus causing an inconsistency between the
> state of the connection (closed) and that of the pool entry (still assumed
> open). The problem is mitigated by the fact that the pooling manager usually
> evicts closed connections almost immediately. There is a small window of time
> in the ThreadSafeClientConnManager#closeIdleConnection method, at which a
> connection can be closed by the IdleConnectionHandler and immediately leased
> from the pool by another thread in an inconsistent state before the main
> thread gets a chance to re-acquire the pool lock and clean out closed
> connections.
> For 4.0.x the problem can be worked around by retaining the pool lock for the
> entire span of the #closeIdleConnection. For the 4.1 branch a better solution
> should be devised. This probably means a complete rewrite or deprecation of
> IdleConnectionHandler.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
