[
https://issues.apache.org/jira/browse/THRIFT-601?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12851539#action_12851539
]
Bryan Duxbury commented on THRIFT-601:
--------------------------------------
Put that way, it's basically impossible to catch an OOM ever, and the only real
solution is to change the way we *allocate* memory. You can already do this in
some ways, but it seems cumbersome.
We could impose a thrift-wide limit on the size of method names, which would
help a bit. However, it wouldn't help in situations when the server genuinely
runs out of memory, for instance as a result of a legitimately overlarge RPC
call. Per-field limits don't really seem like a solution either, I think,
because a lot of people are likely to set the limits to "unlimited".
I believe that the Nonblocking server (as well as HsHa) won't really suffer
from this problem, as long as you set a sane read buffer size. Maybe we should
make the readbuffer setting mandatory? Or perhaps expand the readbuffer thing
to the thread pool server?
> sending random data crashes thrift service
> ------------------------------------------
>
> Key: THRIFT-601
> URL: https://issues.apache.org/jira/browse/THRIFT-601
> Project: Thrift
> Issue Type: Bug
> Components: Library (Java)
> Affects Versions: 0.2
> Reporter: Eric Evans
> Priority: Critical
> Attachments: thrift-601-v2.patch, thrift-601.patch
>
>
> Sending random data to a Java thrift service causes it to crash with extreme
> prejudice.
> dd if=/dev/urandom count=1 | nc $host 9160
> ... produces ...
> java.lang.OutOfMemoryError: Java heap space
> at
> org.apache.thrift.protocol.TBinaryProtocol.readStringBody(TBinaryProtocol.java:296)
> at
> org.apache.thrift.protocol.TBinaryProtocol.readMessageBegin(TBinaryProtocol.java:203)
> at
> org.apache.cassandra.service.Cassandra$Processor.process(Cassandra.java:615)
> at
> org.apache.thrift.server.TThreadPoolServer$WorkerProcess.run(TThreadPoolServer.java:253)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
> at java.lang.Thread.run(Thread.java:636)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
