-
Notifications
You must be signed in to change notification settings - Fork 3.4k
HBASE-28390 WAL value compression fails for cells with large values #5696
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
Conversation
🎊 +1 overall
This message was automatically generated. |
🎊 +1 overall
This message was automatically generated. |
🎊 +1 overall
This message was automatically generated. |
} | ||
} | ||
|
||
private int rawReadInt(InputStream in) 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.
I'm surprised commons-io or our own util code doesn't have something like this 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 tried looking and couldn't find one. I'll try looking 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.
Woops I think IOUtils.readInt should work. Any other comments/concerns other than that?
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.
Left an approving review with the rest. Thanks!
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.
Actually, there is no IOUtils.readInt in commons-io. I realized that the IOUtils I was referring to (while on mobile) was a different library that we don't have a dependency on.
We have a variety of methods for reading ints from byte[] or ByteBuffer, but not for InputStream that I can find. I could read the bytes into a byte[4] and use one of the utils, but I'd rather not allocate an unnecessary byte array. I'm going to leave this alone for now.
@@ -67,14 +71,36 @@ public class CompressedWALTestBase { | |||
Arrays.fill(VALUE, off, (off += 1597), (byte) 'Q'); | |||
} | |||
|
|||
public void doTest(TableName tableName) throws Exception { | |||
@Test |
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.
Thanks for cleaning this up and removing all the unneeded boilerplate.
// if the uncompressed size was larger than the configured buffer size for the codec, | ||
// the BlockCompressorStream will have left an extra 4 bytes hanging. This represents a size | ||
// for the next segment, and it should be 0. See HBASE-28390 | ||
if (lowerIn.available() == 4) { |
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.
This part is ugly but I don't have an alternative suggestion. At least we know both in the WAL read and HFile read cases we won't be contending with a short read, so available is going to be either 0 or 4 and otherwise we'd have had an EOFException thrown.
…5696) Signed-off-by: Andrew Purtell <apurtell@apache.org>
…5696) Signed-off-by: Andrew Purtell <apurtell@apache.org>
…5696) Signed-off-by: Andrew Purtell <apurtell@apache.org>
…5696) Signed-off-by: Andrew Purtell <apurtell@apache.org>
…ith large values (apache#5696) Signed-off-by: Andrew Purtell <apurtell@apache.org>
Unify all of the WAL compression tests to utilize tests defined in the base class. Add a
testLarge
test which writes large buffers. Prior to the fixes in CompressionContext and WALDecompressionBoundedDelegatingInputStream, these tests all failed.