[
https://issues.apache.org/jira/browse/SOLR-9290?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15375821#comment-15375821
]
Hoss Man commented on SOLR-9290:
--------------------------------
I'm no expert but...
bq. I don't understand why the preferred approach here is to just have a thread
that is trying to close connections. Is the problem that these connections
would never otherwise be closed? ...
...my understanding is yes: In a situation where indexing load spikes up, you
can get a lot of connections which are never completely closed. (even if they
are never needed anymore)
bq. ...If that is the case, why can't we solve the problem of them not being
closed as a part of their normal usage? ...
again, IIUC: because they are pooled connections maintained by the HTTP layer.
Per the docs shalin quoted, clients are required to call
ClientConnectionManager#closeExpiredConnections() if they (ie: "we") want to
ensure those connections get closed properly.
bq. It sounds like master doesn't have this problem because of different client
settings? ... Why not backport that and avoid the problem entirely? Is it a
different client version in master or something that makes it not that easy?
master & branch_6x (and earlier) use completely diff http client APIs (see
SOLR-4509) ... the {{HttpClientBuilder.evictIdleConnections}} method shalin
refered to being used on master is on a class ({{HttpClientBuilder}}) that is
not used at all in branch_6x.
The docs of that method describe it doing virtually the same exact same thing
on the (private connection pool for the) HttpClient as what Shalin's patch does
(on the pool in the shared ClientConnectionManager) ...
{noformat}
Makes this instance of HttpClient proactively evict idle connections from the
connection pool using a background thread.
{noformat}
Which makes me wonder...
[~shalinmangar]: why not just re-use the {{IdleConnectionEvictor}} class
provided by httpcomponents (getting the exact same underlying impl as what
master gets from {{HttpClientBuilder.evictIdleConnections}}) ?
https://hc.apache.org/httpcomponents-client-4.4.x/httpclient/apidocs/org/apache/http/impl/client/IdleConnectionEvictor.html
> TCP-connections in CLOSE_WAIT spikes during heavy indexing when SSL is enabled
> ------------------------------------------------------------------------------
>
> Key: SOLR-9290
> URL: https://issues.apache.org/jira/browse/SOLR-9290
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Affects Versions: 5.5.1, 5.5.2
> Reporter: Anshum Gupta
> Priority: Critical
> Attachments: SOLR-9290-debug.patch, SOLR-9290-debug.patch,
> setup-solr.sh
>
>
> Heavy indexing on Solr with SSL leads to a lot of connections in CLOSE_WAIT
> state.
> At my workplace, we have seen this issue only with 5.5.1 and could not
> reproduce it with 5.4.1 but from my conversation with Shalin, he knows of
> users with 5.3.1 running into this issue too.
> Here's an excerpt from the email [~shaie] sent to the mailing list (about
> what we see:
> {quote}
> 1) It consistently reproduces on 5.5.1, but *does not* reproduce on 5.4.1
> 2) It does not reproduce when SSL is disabled
> 3) Restarting the Solr process (sometimes both need to be restarted), the
> count drops to 0, but if indexing continues, they climb up again
> When it does happen, Solr seems stuck. The leader cannot talk to the
> replica, or vice versa, the replica is usually put in DOWN state and
> there's no way to fix it besides restarting the JVM.
> {quote}
> Here's the mail thread:
> http://mail-archives.apache.org/mod_mbox/lucene-solr-user/201607.mbox/%3c46cc66220a8143dc903fa34e79205...@vp-exc01.dips.local%3E
> Creating this issue so we could track this and have more people comment on
> what they see.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
