[
https://issues.apache.org/jira/browse/SOLR-3280?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13246154#comment-13246154
]
Sami Siren commented on SOLR-3280:
----------------------------------
bq. but if something goes wrong (which is very seldom on my systems) the
connection will hang on CLOSE_WAIT and the new index is not swapped in.
do you have idea what this something is, anything in the logs?
bq. The patch is just releasing the connection, if it hangs or not, and keeps
everything operational. So no harm or performance impact for replication.
Yeah I agree. The performance impact is minimal.
> to many / sometimes stale CLOSE_WAIT connections from SnapPuller during /
> after replication
> -------------------------------------------------------------------------------------------
>
> Key: SOLR-3280
> URL: https://issues.apache.org/jira/browse/SOLR-3280
> Project: Solr
> Issue Type: Bug
> Affects Versions: 3.5, 3.6, 4.0
> Reporter: Bernd Fehling
> Assignee: Robert Muir
> Priority: Minor
> Attachments: SOLR-3280.patch
>
>
> There are sometimes to many and also stale CLOSE_WAIT connections
> during/after replication left over on SLAVE server.
> Normally GC should clean up this but this is not always the case.
> Also if a CLOSE_WAIT is hanging then the new replication won't load.
> Dirty work around so far is to fake a TCP connection as root to that
> connection and close it.
> After that the new replication will load, the old index and searcher released
> and the system will
> return to normal operation.
> Background:
> The SnapPuller is using Apache httpclient 3.x and uses the
> MultiThreadedHttpConnectionManager.
> The manager holds a connection in CLOSE_WAIT after its use for further
> requests.
> This is done by calling releaseConnection. But if a connection is stuck it is
> not available any more and a new
> connection from the pool is used.
> Solution:
> After calling releaseConnection clean up with closeIdleConnections(0).
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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]
