Proposed solution: switch to using a ReadWriteLock internally within WorkflowRun to ensure thread-safety of access, and find a way to avoid normal synchronization while obtaining the transient Lock object -- perhaps initializing it at deserialization-time to ensure we don't need to rely on a synchronized lazily-initializing getter.
This should replace the "copyLogsGuard" synchronization object and general synchronization on the WorkflowRun (except for general synchronization during the save operation).
The catch: we need to verify there are no deadlocks between synchronization on the WorkflowRun and the guard object -- we need to ensure synchronization has one consistent order (either run-first or readwriteLock-first).
This message was sent by Atlassian JIRA (v7.3.0#73011-sha1:3c73d0e)
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 [hidden email].
For more options, visit https://groups.google.com/d/optout.