thrift-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bryan Duxbury (JIRA)" <j...@apache.org>
Subject [jira] Commented: (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
Date Fri, 21 Nov 2008 02:48:44 GMT

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


Mime
View raw message