[ 
https://issues.apache.org/jira/browse/HDFS-17049?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17732521#comment-17732521
 ] 

ASF GitHub Bot commented on HDFS-17049:
---------------------------------------

zhangshuyan0 commented on PR #5743:
URL: https://github.com/apache/hadoop/pull/5743#issuecomment-1591127012

   @zhtttylz Thanks for your review. I met this problem because in our  
production code the directory locks have finer granularity, which means 
different files may obtain different locks. It looks that trunk code does not 
has this problem. Thanks again.




> EC: Fix duplicate block group IDs generated by SequentialBlockGroupIdGenerator
> ------------------------------------------------------------------------------
>
>                 Key: HDFS-17049
>                 URL: https://issues.apache.org/jira/browse/HDFS-17049
>             Project: Hadoop HDFS
>          Issue Type: Bug
>            Reporter: Shuyan Zhang
>            Assignee: Shuyan Zhang
>            Priority: Major
>              Labels: pull-request-available
>
> When I used multiple clients to write EC files concurrently, I found that 
> NameNode generated the same block group ID for different files:
> ```
> 2023-06-13 20:09:59,514 INFO org.apache.hadoop.hdfs.StateChange: BLOCK* 
> allocate blk_-9223372036854697568_14389 for /ec-test/10/4068034329705654124
> 2023-06-13 20:09:59,514 INFO org.apache.hadoop.hdfs.StateChange: BLOCK* 
> allocate blk_-9223372036854697568_14390 for /ec-test/19/7042966144171770731
> ```
> After diving into `SequentialBlockGroupIdGenerator`, I found that the current 
> implementation of `nextValue` is not thread-safe.
> This problem must be fixed.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to