-
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-23095 Reuse FileStatus in StoreFileInfo #674
Conversation
@@ -152,7 +166,7 @@ public StoreFileInfo(final Configuration conf, final FileSystem fs, final Path i | |||
*/ | |||
public StoreFileInfo(final Configuration conf, final FileSystem fs, final FileStatus fileStatus) | |||
throws IOException { | |||
this(conf, fs, fileStatus.getPath()); |
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, this is the problem...
} | ||
|
||
private StoreFileInfo(final Configuration conf, final FileSystem fs, final Path initialPath, | ||
final Long createdTimestamp, final Long size) throws IOException { |
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.
What about just passing a FileStatus in?
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 initially thought the same Duo like directly passing "FileStatus" in constructor but what I feel that "Path" is also in same constructor and even that Path can be constructed from FileStatus. So that looks to me not right. :) Another important is Path can not be removed from constructor because many callers pass only Path object, not FileStatus.
I am fine Duo if you still want to change?
public StoreFileInfo(final Configuration conf, final FileSystem fs, final Path initialPath, final FileStatus filestatus)
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 it is fine, as the FileStatus could be null. And maybe you could add a @nullable annotation to indicate this.
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.
Passing the individual params Ts and size looks cleaner IMO. Anyways explained why selected that path.
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.
But this requires extra boxing/unboxing? And what if we need more parameters in the future...
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.
Any way is ok. As this was not in a hot path, even that Autoboxing thing was also ok. That 2 params passing looked more clean from the calling stand point. Anyway not so big concern. This looks clear too.
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.
Thank you @anoopsjohn for the confirmation.
@Apache9 Duo, I already did new commit for your suggestions. Please confirm which one you would like to keep the old or new change?
6f4baae
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.
Its ok.. Keep it as the way u have pushed as of now.. Its ok only.
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.
Sure @anoopsjohn. Thanks again!!
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.
Appreciate Duo @Apache9 if you get some time for review :)
💔 -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.
+1
Nice catch and analysis. Good job.
💔 -1 overall
This message was automatically generated. |
💔 -1 overall
This message was automatically generated. |
@Apache9 Can you please approve? It still be point "change requested". |
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.
+1
Signed-off-by: Anoop Sam John <[email protected]> Signed-off-by: Duo Zhang <[email protected]>
Signed-off-by: Anoop Sam John <[email protected]> Signed-off-by: Duo Zhang <[email protected]>
Signed-off-by: Anoop Sam John <[email protected]> Signed-off-by: Duo Zhang <[email protected]>
Signed-off-by: Anoop Sam John <[email protected]> Signed-off-by: Duo Zhang <[email protected]>
Signed-off-by: Anoop Sam John <[email protected]> Signed-off-by: Duo Zhang <[email protected]> (cherry picked from commit 66506a6) Change-Id: Idd7edd87d0d29024518b8928c1684106ec4f8cc3
We found this performance issue when taking a snapshot on large MOB table where MOB compaction is disabled more than 3 months, is due to MOB data loss issue HBASE-22075.