[jira] [Commented] (ACCUMULO-2360) Need a way to configure TNonblockingServer.maxReadBufferBytes to prevent OOMs from network misbehavour

["John Vines (JIRA)" <ji...@apache.org>]

    [ 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)