Description
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
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)
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.
Attachments
Issue Links
- is duplicated by
-
ACCUMULO-2351 Master memory leak
- Resolved
- is related to
-
ACCUMULO-2897 Thrift proxy in Accumulo throws out of memory error on malformed request
- Resolved
- relates to
-
ACCUMULO-2367 Revisit thrift settings
- Resolved