[
https://issues.apache.org/jira/browse/THRIFT-81?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12649582#action_12649582
]
Bryan Duxbury commented on THRIFT-81:
-------------------------------------
For the time being, I don't think that I'm really worried about the busy loop
effect. It would considerably complicate the code to try to take into account
sockets coming in and out of the selectable list.
I guess I'm not really opposed to upping the default memory limit, though I
don't think that LONG_MAX is the right size to change to. The default JVM heap
size is quite small (256 or 512MB, if I recall), and setting this value high
above that just seems like a recipe for crashes. I can see the argument for
just having out of memory exceptions as the result instead of silently blocking
unexpectedly, though.
I switched to TByteArrayOutputStream instead of ByteArrayOutputStream because
it allows you to get at the underlying array without an array copy. It's just
an optimization that was apparent to me when I was looking at this code.
> TNonblockingServer should have the option to limit the number of clients or
> the amount of memory it will allocate to incomplete client frames
> ---------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: THRIFT-81
> URL: https://issues.apache.org/jira/browse/THRIFT-81
> Project: Thrift
> Issue Type: New Feature
> Components: Library (Java)
> Reporter: Bryan Duxbury
> Assignee: Bryan Duxbury
> Priority: Trivial
> Attachments: thrift-81-v2.patch, thrift-81.patch
>
>
> In the current TNonblockingServer implementation, it would be possible for a
> large number of clients to connect to the server and send a very large 4-byte
> frame size, causing the server to allocate lots of memory and die. The server
> should have an option to protect itself against either overwhelming numbers
> of clients or more than a specified amount of memory at a time, or both. This
> would make it much more robust in the face of an unknown pool of clients.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
