-
Notifications
You must be signed in to change notification settings - Fork 961
[fix] Fix ByteBuf release/retain in PerChannelBookClient #4289
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
Changes from all commits
7e82461
37deb38
64fc771
7a06a97
30c92df
02422ac
475f259
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -842,10 +842,10 @@ void addEntry(final long ledgerId, byte[] masterKey, final long entryId, Referen | |
| cb, ctx, ledgerId, entryId)); | ||
| final Channel c = channel; | ||
| if (c == null) { | ||
| // usually checked in writeAndFlush, but we have extra check | ||
| // because we need to release toSend. | ||
| // Manually release the binary data(variable "request") that we manually created when it can not be sent out | ||
| // because the channel is switching. | ||
| errorOut(completionKey); | ||
| ReferenceCountUtil.release(toSend); | ||
| ReferenceCountUtil.release(request); | ||
| return; | ||
| } else { | ||
| // addEntry times out on backpressure | ||
|
|
@@ -1180,6 +1180,7 @@ private void writeAndFlush(final Channel channel, | |
| if (channel == null) { | ||
| LOG.warn("Operation {} failed: channel == null", StringUtils.requestToString(request)); | ||
| errorOut(key); | ||
| ReferenceCountUtil.release(request); | ||
|
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I think it's the wrong thing to do generally in this method. I'll share a new PR where I explain an alternative approach that handles both the V3 protocol and the UnsafeByteOperations issue and the issue that was found.
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. To trace the context easier, I move the second comment here.
I added a section named |
||
| return; | ||
| } | ||
|
|
||
|
|
@@ -1194,6 +1195,7 @@ private void writeAndFlush(final Channel channel, | |
| StringUtils.requestToString(request)); | ||
|
|
||
| errorOut(key, BKException.Code.TooManyRequestsException); | ||
| ReferenceCountUtil.release(request); | ||
| return; | ||
| } | ||
|
|
||
|
|
@@ -1215,6 +1217,9 @@ private void writeAndFlush(final Channel channel, | |
| } catch (Throwable e) { | ||
| LOG.warn("Operation {} failed", StringUtils.requestToString(request), e); | ||
| errorOut(key); | ||
| // If the request goes into the writeAndFlush, it should be handled well by Netty. So all the exceptions we | ||
| // get here, we can release the request. | ||
| ReferenceCountUtil.release(request); | ||
| } | ||
| } | ||
|
|
||
|
|
||
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.
Does this also result in the correct behavior when
useV2WireProtocol == false?It doesn't look consistent how the V3 protocol is currently handled since there's no retained duplicate and the backing Netty ByteBuf isn't released.
In the case of V3 protocol, the body might consist of com.google.protobuf.NioByteString instances that wrap the Nio ByteBuffer instances backed by Netty ByteBuf instances which also control the lifecycle of the Nio ByteBuffer instances.
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.
It looks like the concern about the NioBuffer lifecycle was raised by @sijie already in the original PR review: #791 (comment) .
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.
Added
releaseat these locationsUh oh!
There was an error while loading. Please reload this page.
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.
No memory leak when
useV2WireProtocolisfalse, but the errorio.netty.util.IllegalReferenceCountException: refCnt: 0, increment: 1described in the Motivation will also occur.