hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Liam Williams (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HTTPCLIENT-1583) Add option to create a connection eviction thread for a non-shared connection manager
Date Sun, 19 Mar 2017 19:49:42 GMT

    [ https://issues.apache.org/jira/browse/HTTPCLIENT-1583?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15931913#comment-15931913

Liam Williams commented on HTTPCLIENT-1583:


I am taking a look at [HTTPCLIENT-1830|https://issues.apache.org/jira/browse/HTTPCLIENT-1830]
and I noticed something strange in this commit:
git-svn-id: https://svn.apache.org/repos/asf/httpcomponents/httpclient/trunk@1643671 13f79535-47bb-0310-9956-ffa450edef68

The `IdleConnectionEvictor` seems like it was designed to support either evicting either expired
connections only (via `HttpClientBuilder.evictExpiredConnections`) or additionally evicting
idle connections too (via `HttpClientBuilder.evictIdleConnections`).

Unfortunately, it seems that the functionality of evicting only expired connections has always
been dead code, since the `HttpClientBuilder` will default the maxIdleTime to 10 seconds if
only `HttpClientBuilder.evictExpiredConnections` is called and not `HttpClientBuilder.evictIdleConnections`.

Can you please clarify what the intended behaviour is?


> Add option to create a connection eviction thread for a non-shared connection manager
> -------------------------------------------------------------------------------------
>                 Key: HTTPCLIENT-1583
>                 URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1583
>             Project: HttpComponents HttpClient
>          Issue Type: Improvement
>    Affects Versions: 4.3.5
>            Reporter: yair ogen
>            Priority: Minor
>             Fix For: 4.4 Final
> In the tutorial:
> http://hc.apache.org/httpcomponents-client-ga/tutorial/html/connmgmt.html, section 2.5
Connection eviction policy - you explain how to clean-up connections. Although I can argue
against the design as without this if server closes connections, my client gets many sockets
stuck on CLOSE_WAIT - adding this thread solves the CLOSE_WAIT issue. 
> However, I don't understand why you don't do this yourself if keep-alive is set. I would
expect the library to support such a thread. In the meanwhile, it seems that if I use the
default connection manager, I can't use non-deprecated code to call :
> connMgr.closeExpiredConnections();
> and
> connMgr.closeIdleConnections(30, TimeUnit.SECONDS);
> This is because the only exposed API to get the default pooling connection manager is
by calling:
> httpClient.getConnectionManager(), which is deprecated. Javadoc suggests to go to the
builder (which I do use but not for creating connection pool as the default is good enough
for me) which is useless.
> So - how should one acquire a reference to the connection manager?

This message was sent by Atlassian JIRA

To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org

View raw message