[
https://issues.apache.org/jira/browse/HTTPCLIENT-1108?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13067663#comment-13067663
]
Oleg Kalnichevski commented on HTTPCLIENT-1108:
-----------------------------------------------
@Jon
I spotted a few problems with the latest changes. Firstly, it appears the
behaviour of #deleteLeastUsedEntry no longer corresponds to its contract. Does
not it remove the most used entry now instead of the least one? Secondly, Stack
is effectively a Vector. Methods of Vector class are synchronised, which is an
unnecessary overhead as far as I can tell, since the internal structures of the
class are guarded by poolLock. Wouldn't it be more efficient to use LinkedList
instead of Vector?
Oleg
> different connection reuse strategy would reduce number of open connections
> ---------------------------------------------------------------------------
>
> Key: HTTPCLIENT-1108
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1108
> Project: HttpComponents HttpClient
> Issue Type: Improvement
> Components: HttpClient
> Affects Versions: 4.1.1
> Reporter: Jon Moore
> Assignee: Jon Moore
> Priority: Minor
> Fix For: 4.1.2
>
>
> Currently, the ThreadSafeClientConnManager reuses persistent connections in a
> round-robin fashion: when the connection is checked back into the pool, it is
> added to a queue of available connections for later use. This has the perhaps
> unintended effect that the client may keep open more connections than needed,
> because the "last used" time keeps getting updated and none of the
> connections can get reclaimed via closeIdleConnections().
> Exchanging the queue (FIFO) for a stack (LIFO) would result in extra
> connections actually becoming idle for long enough to be reclaimed.
> I have a working patch for this; just need to get my act together to get it
> in.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
