[jira] [Commented] (SOLR-3280) to many / sometimes stale CLOSE_WAIT connections from SnapPuller during / after replication
[ https://issues.apache.org/jira/browse/SOLR-3280?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13742478#comment-13742478 ] David Fu commented on SOLR-3280: I am still on 3.4 now. I noticed the solr4 pretty much reimplemented the snappuller and am thinking about upgrading to v4. Just out of the curiosity, what are some issues you faced in the process of upgrading from 3.6 to 4.2.1? > 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-ALPHA >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 For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3280) to many / sometimes stale CLOSE_WAIT connections from SnapPuller during / after replication
[ https://issues.apache.org/jira/browse/SOLR-3280?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13741426#comment-13741426 ] David Fu commented on SOLR-3280: I am facing the same problem. Any update on when this will be resolved? > 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-ALPHA >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 For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
