[
https://issues.apache.org/jira/browse/HDFS-16139?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17386822#comment-17386822
]
Xiaoqiao He commented on HDFS-16139:
------------------------------------
Thanks [~vjasani] for your report and contributions.
{quote}BPServiceActor#Scheduler's nextBlockReportTime is declared volatile and
it can be assigned/read by testing threads (through BPServiceActor#triggerXXX)
as well as by actor threads. {quote}
Do you means that it could be executed unexpected when run unit test? When
deploy on production environment this variable is accessed/updated by Scheduler
only?
> Update BPServiceActor Scheduler's nextBlockReportTime atomically
> ----------------------------------------------------------------
>
> Key: HDFS-16139
> URL: https://issues.apache.org/jira/browse/HDFS-16139
> Project: Hadoop HDFS
> Issue Type: Task
> Reporter: Viraj Jasani
> Assignee: Viraj Jasani
> Priority: Major
> Labels: pull-request-available
> Time Spent: 20m
> Remaining Estimate: 0h
>
> BPServiceActor#Scheduler's nextBlockReportTime is declared volatile and it
> can be assigned/read by testing threads (through BPServiceActor#triggerXXX)
> as well as by actor threads. Hence it is declared volatile but it is still
> assigned non-atomically
> e.g
> {code:java}
> if (factor != 0) {
> nextBlockReportTime += factor * blockReportIntervalMs;
> } else {
> // If the difference between the present time and the scheduled
> // time is very less, the factor can be 0, so in that case, we can
> // ignore that negligible time, spent while sending the BRss and
> // schedule the next BR after the blockReportInterval.
> nextBlockReportTime += blockReportIntervalMs;
> }
> {code}
> We should convert it to AtomicLong to take care of concurrent assignments
> while making sure that it is assigned atomically.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]