[
https://issues.apache.org/jira/browse/ACCUMULO-2360?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13899459#comment-13899459
]
John Vines commented on ACCUMULO-2360:
--------------------------------------
I think reusing the same property makes the most sense here, since I think this
property was the original hope of that property. We can revisit that property
if we decide it doesn't make sense as at the transport frame level (as opposed
to server socket frame).
> Need a way to configure TNonblockingServer.maxReadBufferBytes to prevent OOMs
> from network misbehavour
> ------------------------------------------------------------------------------------------------------
>
> Key: ACCUMULO-2360
> URL: https://issues.apache.org/jira/browse/ACCUMULO-2360
> Project: Accumulo
> Issue Type: Bug
> Components: master, tserver
> Affects Versions: 1.5.0
> Reporter: John Vines
> Assignee: John Vines
> Priority: Blocker
> Fix For: 1.5.1, 1.6.0
>
>
> 1.5.0 introduced GENERAL_MAX_MESSAGE_SIZE (ACCUMULO-1141), a parameter to set
> the maximum frame size for the TFramedTransport. However, there is an
> underlying frame (I think this is a glossary conflict) read in
> TNonblockingServer that can still cause OOM errors if erroneously connected
> to (telnet, netcat, etc.), creating a stack trace as such
> {code}2014-02-12 10:26:40,439 [util.TServerUtils$THsHaServer] ERROR: run()
> exiting due to uncaught error
> java.lang.OutOfMemoryError: Java heap space
> at java.nio.HeapByteBuffer.<init>(HeapByteBuffer.java:57)
> at java.nio.ByteBuffer.allocate(ByteBuffer.java:329)
> at
> org.apache.thrift.server.AbstractNonblockingServer$FrameBuffer.read(AbstractNonblockingServer.java:338)
> at
> org.apache.thrift.server.AbstractNonblockingServer$AbstractSelectThread.handleRead(AbstractNonblockingServer.java:202)
> at
> org.apache.thrift.server.TNonblockingServer$SelectAcceptThread.select(TNonblockingServer.java:198)
> at
> org.apache.thrift.server.TNonblockingServer$SelectAcceptThread.run(TNonblockingServer.java:154){code}
> I believe if we set maxReadBufferBytes to the server arguments, it will
> filter appropriately. The only decision I'm not sure about is if we should
> recycle the max message property or have a separate one.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
