|
||||||||
|
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 |
||||||||
You received this message because you are subscribed to the Google Groups "Jenkins Issues" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
> I'm not sure what you mean by escalating the Jenkins.removeNode() code - could the public removeNode() be unsynchronized, obtain a lock on the Queue, then call a private, synchronized removeNode() method?
I think it just needs analysis to ensure that the lock on Jenkins is either always before the Queue lock or always after the Queue lock... the sad thing is that the list is a copy on write... but probably safer is just to fix durable task's retention strategy