magibney commented on PR #842: URL: https://github.com/apache/solr/pull/842#issuecomment-1122407472
Thanks @risdenk! Both the "SolrZooKeeper" and the always-synchronous close() are codependent, iiuc. My hesitance to go full "blocking close()" across the board comes down to the fact that introducing a blocking method introduces new possibilities for actual _deadlock_. Paired with my [increasing sense that this may be chasing an issue of very little practical significance](https://issues.apache.org/jira/browse/SOLR-15660?focusedCommentId=17533066#comment-17533066), I'm not sure it's worth the risk to make any change at all here unless we're reasonably certain that the possibility for deadlock is adequately covered by existing tests, and/or we anticipate more substantial benefits than just "avoiding test failures for short-lived thread leaks" -- ThreadLeakLinger would avoid test failures, and may well be entirely appropriate in this case. I guess the way I'm thinking about this now: this is a "real" issue, but not necessarily a significant one, and the fix carries its own risks (arguably more significant -- deadlock -- than the risks of the existing issue). I'd like to get some consensus over whether there are any benefits (e.g., avoiding Zk reconnect storms/thrashing?) to a synchronous approach to close(). If there's consensus that making ZooKeeper.close() synchronous across the board is likely the correct way to go, I'm fine with that (probably following the SolrZooKeeper approach you suggested). We could let it bake for a while before porting to a release branch. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
