[
https://issues.apache.org/jira/browse/BEAM-6561?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16758558#comment-16758558
]
Dustin Rhodes edited comment on BEAM-6561 at 2/1/19 6:51 PM:
-------------------------------------------------------------
whoops meant to put this on 6562
was (Author: dustin12):
I believe this is because there is synchronization on batches, a
ConcurrentLinkedDeque, to enforce the atomicity of a sequence of method calls
on it. As far as I'm aware this pattern is error prone (or at least confusing)
as ConcurrentLinkedDeque does not make any guarantees about using itself as a
lock for its internal operations so there is not guarantee that the
synchronized blocks run atomically.
Is best practice here to switch it to a standard LinkedDeque and do all the
synchronization on it manually so that we are sure the synchronized blocks are
atomic? Is there an easy way (a gradle command) I can run Findbugs to confirm
that this is the bug its finding (although I'm pretty sure)?
> WorkProgressUpdater synchronizes on java.util.concurrent classes
> ----------------------------------------------------------------
>
> Key: BEAM-6561
> URL: https://issues.apache.org/jira/browse/BEAM-6561
> Project: Beam
> Issue Type: Bug
> Components: runner-dataflow
> Reporter: Kenneth Knowles
> Priority: Major
>
> Findbugs caught this. There seems to be synchronization on variables where
> the classes themselves have their own mechanisms. If intended, it should be
> made more clear by simple mutexes.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
