[
https://issues.apache.org/jira/browse/SOLR-3280?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13246139#comment-13246139
]
Bernd Fehling commented on SOLR-3280:
-------------------------------------
Nope, no firewall. I have 1 master and 2 slaves on the same lan. After
replication finished the connection on master is closed, the connection on
slave is in CLOSE_WAIT with a Receive-Queue 1 byte. If everything goes well the
connection will be reused by MultiThreadedHttpConnectionManager, 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.
If you use jvisualvm on that slave and go to the MBeans tab you can see "solr/"
in the tree but you can't open it because there is no sub-tree.
The patch is just releasing the connection, if it hangs or not, and keeps
everything operational. So no harm or performance impact for replication.
> 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]
