[
https://issues.apache.org/jira/browse/SOLR-9290?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15375666#comment-15375666
]
David A. Bradley commented on SOLR-9290:
----------------------------------------
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? If that is the case, why can't we solve the
problem of them not being closed as a part of their normal usage? It sounds
like master doesn't have this problem because of different client settings? :
"Also, I think the reason this wasn't reproducible on master is because
SOLR-4509 enabled eviction of idle connections by calling
HttpClientBuilder#evictIdleConnections with a 50 second limit."
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?
"So we must periodically close such connections once they're idle to avoid the
number of such connections increasing to absurd limits." It seems from the
discussion here that the problem is hitting a high number of connections, which
is only allowed to be so high because we asked for it. What if this thread lags
behind enough that the connections get too high? It sounds like the purpose of
this thread is to race to prevent Solr from doing what we asked it to do.
The idea of having a thread to deal with any connections that end up in a bad
state unexpectedly makes sense, but is the cause of all these CLOSE_WAIT
connections really from unexpected behavior?
I feel like I must be missing something.
> 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
