[
https://issues.apache.org/jira/browse/SOLR-5721?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13900037#comment-13900037
]
Mark Miller commented on SOLR-5721:
-----------------------------------
Nice! Good call.
> ConnectionManager can become stuck in likeExpired
> -------------------------------------------------
>
> Key: SOLR-5721
> URL: https://issues.apache.org/jira/browse/SOLR-5721
> Project: Solr
> Issue Type: Bug
> Components: SolrCloud
> Affects Versions: 5.0, 4.7
> Reporter: Gregory Chanan
> Attachments: SOLR-5721.patch, SOLR-5721test.patch
>
>
> Here are the sequence of events:
> - we disconnect
> - The disconnect timer beings to run (so no longer scheduled), but doesn't
> set likelyExpired yet
> - We connect, and set likelyExpired = false
> - The disconnect thread runs and sets likelyExpired to true, and it is never
> set back to false (note that we cancel the disconnect thread but that only
> cancels scheduled tasks but not running tasks).
> This is pretty difficult to reproduce without doing more work in the
> disconnect thread. It's easy to reproduce by adding sleeps in various places
> -- I have a test that I'll attach that does that.
> The most straightforward way to solve this would be to grab the
> synchronization lock on ConnectionManager in the disconnect thread, ensure we
> aren't actually connected, and only then setting likelyExpired to true. In
> code:
> {code}
> synchronized (ConnectionManager.this) {
> if (!connected) likelyExpired = true;
> }
> {code}
> but this is all pretty subtle and error prone. It's easier to just get rid
> of the disconnect thread and record the last time we disconnected. Then,
> when we check likelyExpired, we just do a quick calculation to see if we are
> likelyExpired.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
