John Vines created ACCUMULO-2360:
------------------------------------
Summary: 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: Critical
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)
