[
https://issues.apache.org/jira/browse/HADOOP-2910?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12587002#action_12587002
]
Doug Cutting commented on HADOOP-2910:
--------------------------------------
> The new patch keeps the old IPC server behavior [ ... ]
Which behaviour is that? Isn't the old behaviour buggy?
> This patch simply says that it depends on O.S. to decide when to refuse a
> connection.
No, this patch keeps accepting connections until it runs out of file handles,
then starts logging exceptions as it tries to accept more but fails because it
has run out of file handles. File handle exhaustion may also cause requests in
progress that do i/o to fail too.
Wouldn't it be more reliable to limit the number of connections? In the
interests of simplifying configuration, it seems reasonable to limit this to
the call queue length as an upper bound, as was done in the prior version.
The backlog isn't a panacea, its simply a way to efficiently queue more
clients. On the operating systems where folks run Hadoop, it should be
effective at this, so we shouldn't ignore it, should we?
> Throttle IPC Client/Server during bursts of requests or server slowdown
> -----------------------------------------------------------------------
>
> Key: HADOOP-2910
> URL: https://issues.apache.org/jira/browse/HADOOP-2910
> Project: Hadoop Core
> Issue Type: Improvement
> Components: ipc
> Affects Versions: 0.16.0
> Reporter: Hairong Kuang
> Assignee: Hairong Kuang
> Fix For: 0.18.0
>
> Attachments: callQueue.patch, callQueue1.patch, callQueue2.patch,
> callQueue3.patch, throttleClient.patch
>
>
> I propose the following to avoid an IPC server being swarmed by too many
> requests and connections
> 1. Limit call queue length or limit the amount of memory used in the call
> queue. This can be done by including the size of a request in the header and
> storing unmarshaled requests in the call queue.
> 2. If the call queue is full or queue buffer is full, stop reading requests
> from sockets. So requests stay at the server's system buffer or at the client
> side and thus eventually throttle the client.
> 3. Limit the total number of connections. Do not accept new connections if
> the connection limit is exceeded. (Note: this solution is unfair to new
> connections.)
> 4. If receive out of memory exception, close the current connection.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
