[
https://issues.apache.org/jira/browse/THRIFT-81?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12649559#action_12649559
]
David Reiss commented on THRIFT-81:
-----------------------------------
If you want to avoid the busy wait, the best way that I can think of would be
to remove the socket in question from the selectable set until some memory is
freed up. This change is not strictly necessary, but I think we should
probably turn the default max buffer size up to something like LONG_MAX to
avoid running into it unless you are sure you know what you are doing.
What is the purpose of the changes to response_ near the bottom of the patch?
> 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.
