danny0405 commented on code in PR #12982:
URL: https://github.com/apache/hudi/pull/12982#discussion_r2032325157
##########
hudi-common/src/main/java/org/apache/hudi/common/table/view/AbstractTableFileSystemView.java:
##########
@@ -177,31 +178,39 @@ public List<HoodieFileGroup>
addFilesToView(List<StoragePathInfo> statuses) {
* Adds the provided statuses into the file system view for a single
partition, and also caches it inside this object.
*/
public List<HoodieFileGroup> addFilesToView(String partitionPath,
List<StoragePathInfo> statuses) {
- HoodieTimer timer = HoodieTimer.start();
- List<HoodieFileGroup> fileGroups = buildFileGroups(partitionPath,
statuses, visibleCommitsAndCompactionTimeline, true);
- long fgBuildTimeTakenMs = timer.endTimer();
- timer.startTimer();
- // Group by partition for efficient updates for both InMemory and
DiskBased structures.
-
fileGroups.stream().collect(Collectors.groupingBy(HoodieFileGroup::getPartitionPath))
- .forEach((partition, value) -> {
- if (!isPartitionAvailableInStore(partition)) {
- if (bootstrapIndex.useIndex()) {
- try (BootstrapIndex.IndexReader reader =
bootstrapIndex.createReader()) {
- LOG.info("Bootstrap Index available for partition {}",
partition);
- List<BootstrapFileMapping> sourceFileMappings =
- reader.getSourceFileMappingForPartition(partition);
- addBootstrapBaseFileMapping(sourceFileMappings.stream()
- .map(s -> new BootstrapBaseFileMapping(new
HoodieFileGroupId(s.getPartitionPath(),
- s.getFileId()), s.getBootstrapFileStatus())));
+ try {
+ writeLock.lock();
Review Comment:
> You are correct that this can happen but it can also happen currently
I can happen but the read API would not nullify the existing mapping items,
while after your change, the `#sync` can clear the just updated item, and the
query would return wrong result set.
##########
hudi-common/src/main/java/org/apache/hudi/common/table/view/AbstractTableFileSystemView.java:
##########
@@ -177,31 +178,39 @@ public List<HoodieFileGroup>
addFilesToView(List<StoragePathInfo> statuses) {
* Adds the provided statuses into the file system view for a single
partition, and also caches it inside this object.
*/
public List<HoodieFileGroup> addFilesToView(String partitionPath,
List<StoragePathInfo> statuses) {
- HoodieTimer timer = HoodieTimer.start();
- List<HoodieFileGroup> fileGroups = buildFileGroups(partitionPath,
statuses, visibleCommitsAndCompactionTimeline, true);
- long fgBuildTimeTakenMs = timer.endTimer();
- timer.startTimer();
- // Group by partition for efficient updates for both InMemory and
DiskBased structures.
-
fileGroups.stream().collect(Collectors.groupingBy(HoodieFileGroup::getPartitionPath))
- .forEach((partition, value) -> {
- if (!isPartitionAvailableInStore(partition)) {
- if (bootstrapIndex.useIndex()) {
- try (BootstrapIndex.IndexReader reader =
bootstrapIndex.createReader()) {
- LOG.info("Bootstrap Index available for partition {}",
partition);
- List<BootstrapFileMapping> sourceFileMappings =
- reader.getSourceFileMappingForPartition(partition);
- addBootstrapBaseFileMapping(sourceFileMappings.stream()
- .map(s -> new BootstrapBaseFileMapping(new
HoodieFileGroupId(s.getPartitionPath(),
- s.getFileId()), s.getBootstrapFileStatus())));
+ try {
+ writeLock.lock();
Review Comment:
> You are correct that this can happen but it can also happen currently
It can happen but the read API would not nullify the existing mapping items,
while after your change, the `#sync` can clear the just updated item, and the
query would return wrong result set.
--
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: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
