Github user adeneche commented on a diff in the pull request:
https://github.com/apache/drill/pull/446#discussion_r57524389
--- Diff:
exec/rpc/src/main/java/org/apache/drill/exec/rpc/ProtobufLengthDecoder.java ---
@@ -82,15 +79,7 @@ protected void decode(ChannelHandlerContext ctx, ByteBuf
in, List<Object> out) t
} else {
// need to make buffer copy, otherwise netty will try to refill
this buffer if we move the readerIndex forward...
// TODO: Can we avoid this copy?
- ByteBuf outBuf;
- try {
- outBuf = allocator.buffer(length);
- } catch (OutOfMemoryException e) {
- logger.warn("Failure allocating buffer on incoming stream due
to memory limits. Current Allocation: {}.", allocator.getAllocatedMemory());
- in.resetReaderIndex();
- outOfMemoryHandler.handle();
- return;
- }
+ ByteBuf outBuf = allocator.buffer(length);
--- End diff --
So I was looking at how we are using `ProtobufLengthDecoder` in our code,
and we use in the control, server and user tunnels both on the client and
server side.
If I am not mistaken, the only derived class from ProtobufLengthDecoder
that actually uses an rpc allocator is UserProtobufLengthDecoder and only on
the server side of the user tunnel. All other implementations use the root
allocator.
This may actually explain why I wasn't able to reproduce this issue no
matter how much I reduced the "rpc:bit-data" max allocation.
am I missing something ?
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at [email protected] or file a JIRA ticket
with INFRA.
---
