[ 
https://issues.apache.org/jira/browse/HDFS-16139?focusedWorklogId=628194&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-628194
 ]

ASF GitHub Bot logged work on HDFS-16139:
-----------------------------------------

                Author: ASF GitHub Bot
            Created on: 27/Jul/21 06:57
            Start Date: 27/Jul/21 06:57
    Worklog Time Spent: 10m 
      Work Description: Hexiaoqiao merged pull request #3228:
URL: https://github.com/apache/hadoop/pull/3228


   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: common-issues-unsubscr...@hadoop.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


Issue Time Tracking
-------------------

    Worklog Id:     (was: 628194)
    Time Spent: 0.5h  (was: 20m)

> 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: 0.5h
>  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: hdfs-issues-unsubscr...@hadoop.apache.org
For additional commands, e-mail: hdfs-issues-h...@hadoop.apache.org

Reply via email to