-
Notifications
You must be signed in to change notification settings - Fork 907
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
BufferedChannel's read(ByteBuf, long, int) gets stuck in loop #4503
Comments
I think we can verification and throw an exception while the length of the byte array to be read exceeds the length of the dest Bytebuf, to avoid fall into a dead loop |
A workaround is setting the correct initial capacity for the destination ByteBuf (e.g. in testing class, the method overload allocBuf() should be modified to accept an integer and pass it as initial capacity for ByteBufAllocator.DEFAULT.buffer()). Having proper checks (even at the beginning of the BufferedChannel.read method) will of course fix this issue definitively, or you may specify this requirement in javadoc (to explicitly set the dest ByteBuf's initial capacity to be greater than or equal to read passed value "length"), or even let BufferedChannel's read to expand the destination ByteBuf object's capacity according to the "length" (e.g. if length > destBufLength then exceed capacity by length - destBufLength) actual value passed to BufferedChannel.read's parameter. Another valid behaviour would be to partially read until the dest buf is full. |
I would add the assertion and not change the behavior, as reallocations may lead to unwanted side effects. This is not a public API and we have control over the usage of the class. @StefanoBelli would you send a PR to address your problem ? |
Sure, I will within the next few hours |
BUG REPORT
Describe the bug
While testing BufferedChannel's read instance method (with buf capacity=100B, wrote data through the buffered channel=300B),
it happens that when the read's formal parameter "length" is greater than 256, read gets stuck in a loop for some reason.
So if i want to read from pos=43, length=256 then test succeeds, but for pos=43, length=257 we have an endless loop.
Exchanging parameters actual values (from pos=43, length=257 to pos=256, length=43, considering that pos is an index)
results in a good test outcome.
To Reproduce
Run this test (emplace under bookkeeper-server/src/test/java/...): parameterized JUnit runner allows to run same test
with different params: the publicly-available static method "params()" (annotated with "Parameters")
in BufferedChannelTest provides those params - in our case those params are pos and length being passed to the
read() function of BufferedChannel (see test method).
Commented out params are the one that fails, above each one there are the same exchanged values (which works for some reason)
Expected behavior
Test assertion should pass anyway, with any combination of pos, length
The text was updated successfully, but these errors were encountered: