[
https://issues.apache.org/jira/browse/SOLR-13352?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16807027#comment-16807027
]
Hoss Man commented on SOLR-13352:
---------------------------------
Thanks shalin,
I think that comment was more confusing then helpful considering the ambiguity
of which of the two nested try blocks it was refering to.
In generally, a Lock should *NEVER* be acquired _inside_ the try/finally where
the lock is released (that's pretty fundamental to the design of the Lock API)
and now that we only catch InterruptedException in the outer try/catch, there
shouldn't be much risk of confusion in the future of people thinking that maybe
the lock call should be moved inside the inner try.
> possible deadlock/threadleak from OverseerTriggerThread/AutoScalingWatcher
> during close()
> -----------------------------------------------------------------------------------------
>
> Key: SOLR-13352
> URL: https://issues.apache.org/jira/browse/SOLR-13352
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Reporter: Hoss Man
> Assignee: Hoss Man
> Priority: Major
> Attachments: SOLR-13352.patch,
> sarowe_Lucene-Solr-tests-master_20462.log.txt
>
>
> A recent jenkins failure in TestSimTriggerIntegration lead me to what appears
> to be a "lock leak" situation in OverseerTriggerThread in how the
> "updateLock" object is dealt with in the event that the OverseerTriggerThread
> is closed.
> It's possible that this only affects tests using the SimCloudManager when
> calling "simRestartOverseer" -- but
> I _believe_ this can lead also lead to an actual deadlock / threadleak
> situation in a thread running AutoScalingWatcher (that hold a refrefrences to
> OverseerTriggerThread and every object reachable from it) when the
> OverseerTriggerThread is closed as part of a real Solr shutdown ... which i
> think would cause the JVM to stall untill externally killed.
> ----
> If my analysis of the test failure (to follow in comment) is correct, then
> even even if this bug isn't likely to affect real world solr instances (and
> only surfaces because of how OverseerTriggerThread is used in
> SimCloudManager) the fix to OverseerTriggerThread is a trivial change to
> follow locking best practices (patch to follow)
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
