[jira] Updated: (THRIFT-81) TNonblockingServer should have the option to limit the number of clients or the amount of memory it will allocate to incomplete client frames

["Bryan Duxbury (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/THRIFT-81?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bryan Duxbury updated THRIFT-81:
--------------------------------

    Attachment: thrift-81.patch

Here's my first shot at fixing this. The patch adds a configurable max read buffer size and accounts for how much space is already allocated. If the next frame would go past the limit, it skips that frame until the next pass through the select loop. If the frame being sent is bigger than the limit all by itself, the connection is immediately closed.

One possible concern is that the select loop might spin really fast when all memory is used up if the requests being processed aren't going very quickly. The selector will just keep on coming back through the readable (but too large) FrameBuffers without any pausing. I'm not sure if there's a good way to deal with this, though.

I would appreciate a code review.

> 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.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.