-
Notifications
You must be signed in to change notification settings - Fork 3.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
HBASE-27021 StoreFileInfo should set its initialPath in a consistent way #4419
Conversation
💔 -1 overall
This message was automatically generated. |
💔 -1 overall
This message was automatically generated. |
💔 -1 overall
This message was automatically generated. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I assume you've spot-checked the output of TestHStore after this and verified things work as expected?
+1 from me if so
@@ -119,18 +119,18 @@ public class StoreFileInfo implements Configurable { | |||
*/ | |||
public StoreFileInfo(final Configuration conf, final FileSystem fs, final Path initialPath, | |||
final boolean primaryReplica) throws IOException { | |||
this(conf, fs, null, initialPath, primaryReplica); | |||
this(conf, fs, fs.getFileStatus(initialPath), primaryReplica); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should make sure constructor javadoc is updated as this is a Namenode call. If we call this often, we're incurring remote reads which could be a bad perf hit. Need to make sure current callers are behaving nicely (we should be caching StoreFileInfo's already)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this is intentional, we want to reduce the request to namenode...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok, haven't thought about that. Let me revert this, and sanitize the path, instead.
sf = it.next(); | ||
} | ||
sf.closeStoreFile(true); | ||
store.getStoreEngine().getStoreFileManager().removeCompactedFiles(Lists.newArrayList(sf)); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: Collections.singletonList(sf)
might be a little less heavy than a new ArrayList (since you're changing this)
I think the key problem here is we use StoreFileInfo as the key of a hash map. In general, within a typical store, we just need to use the storefile's name to decide whether they are the same StoreFileInfo. Or at least, when comparing, we should normalize the Path object to the same format... |
OK, there is a FileSystem instance in the StoreFileInfo, so I think we just need to make a makeQualified to normalize the initial path? |
Yep, TestHStore was fine, but noticed TestStoreFileInfo failed here. Need to double check on that. |
💔 -1 overall
This message was automatically generated. |
💔 -1 overall
This message was automatically generated. |
🎊 +1 overall
This message was automatically generated. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
New patch looks good too.
…way (#4419) Signed-off-by: Josh Elser <elserj@apache.org> Signed-off-by: Duo Zhang <zhangduo@apache.org>
…way (#4419) Signed-off-by: Josh Elser <elserj@apache.org> Signed-off-by: Duo Zhang <zhangduo@apache.org>
…way (apache#4419) Change-Id: I3d8a68d73fb91a31e0c8c41f50bf2cc06ff00685 Signed-off-by: Josh Elser <elserj@apache.org> Signed-off-by: Duo Zhang <zhangduo@apache.org>
No description provided.