[
https://issues.apache.org/jira/browse/BEAM-6431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16752919#comment-16752919
]
Alex Amato commented on BEAM-6431:
----------------------------------
I have moved the ExecutionStateSampler and ExecutionStateTracker in a PR but I
am seeing some findbug issues
So I am adding the @NotThreadSafe, but we should address or surpess these
individually
||Code||Warning||
|IS|Inconsistent synchronization of
org.apache.beam.runners.core.metrics.ExecutionStateTracker.trackedThread;
locked 66% of time|
| |[Bug type IS2_INCONSISTENT_SYNC (click for details)|#IS2_INCONSISTENT_SYNC]
In class org.apache.beam.runners.core.metrics.ExecutionStateTracker
Field org.apache.beam.runners.core.metrics.ExecutionStateTracker.trackedThread
Synchronized 66% of the time
Unsynchronized access at ExecutionStateTracker.java:[line 267]
Unsynchronized access at ExecutionStateTracker.java:[line 196]
Synchronized access at ExecutionStateTracker.java:[line 178]
Synchronized access at ExecutionStateTracker.java:[line 188]
Synchronized access at ExecutionStateTracker.java:[line 201]
Synchronized access at ExecutionStateTracker.java:[line 203]|
|VO|Increment of volatile field
org.apache.beam.runners.core.metrics.ExecutionStateTracker.numTransitions in
org.apache.beam.runners.core.metrics.ExecutionStateTracker.enterState(ExecutionStateTracker$ExecutionState)|
| |[Bug type VO_VOLATILE_INCREMENT (click for details)|#VO_VOLATILE_INCREMENT]
In class org.apache.beam.runners.core.metrics.ExecutionStateTracker
In method
org.apache.beam.runners.core.metrics.ExecutionStateTracker.enterState(ExecutionStateTracker$ExecutionState)
Field org.apache.beam.runners.core.metrics.ExecutionStateTracker.numTransitions
At ExecutionStateTracker.java:[line 224]|
h2. IS2_INCONSISTENT_SYNC: Inconsistent synchronization
The fields of this class appear to be accessed inconsistently with respect to
synchronization. This bug report indicates that the bug pattern detector
judged that
* The class contains a mix of locked and unlocked accesses,
* The class is *not* annotated as javax.annotation.concurrent.NotThreadSafe,
* At least one locked access was performed by one of the class's own methods,
and
* The number of unsynchronized field accesses (reads and writes) was no more
than one third of all accesses, with writes being weighed twice as high as reads
A typical bug matching this bug pattern is forgetting to synchronize one of the
methods in a class that is intended to be thread-safe.
You can select the nodes labeled "Unsynchronized access" to show the code
locations where the detector believed that a field was accessed without
synchronization.
Note that there are various sources of inaccuracy in this detector; for
example, the detector cannot statically detect all situations in which a lock
is held. Also, even when the detector is accurate in distinguishing locked vs.
unlocked accesses, the code in question may still be correct.
> Add ExecutionTime metrics to the Beam Java SDK
> ----------------------------------------------
>
> Key: BEAM-6431
> URL: https://issues.apache.org/jira/browse/BEAM-6431
> Project: Beam
> Issue Type: New Feature
> Components: java-fn-execution
> Reporter: Alex Amato
> Assignee: Alex Amato
> Priority: Major
> Time Spent: 1h 20m
> Remaining Estimate: 0h
>
> This will be done by using the Dataflow worker's StateSampler code. I have
> put together a refactoring plan
> [here|https://docs.google.com/document/d/1OlAJf4T_CTL9WRH8lP8uQOfLjWYfm8IpRXSe38g34k4/edit#]
> This will include estimating the processing time for the start, process and
> finish bundle. The python SDK already has an implementation of this.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
