[
https://issues.apache.org/jira/browse/HDFS-17049?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17732829#comment-17732829
]
ASF GitHub Bot commented on HDFS-17049:
---------------------------------------
Hexiaoqiao commented on PR #5743:
URL: https://github.com/apache/hadoop/pull/5743#issuecomment-1592286013
> @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
have this problem. Thanks again.
cc @umamaheswararao FYI.
> 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]
