[ 
https://issues.apache.org/jira/browse/HADOOP-2910?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12587016#action_12587016
 ] 

Hairong Kuang commented on HADOOP-2910:
---------------------------------------

> Which behaviour is that? 
Server continues to accept connections even when its call queue is full. It 
does not impose a limitation on the number of connections.

> this patch keeps accepting connections until it runs out of file handles.
The number of connections that a server can accept might be far less than the 
number of file handles. I think TCP/IP will reject a connection before the 
acceptor calls accept.

> it seems reasonable to limit this to the call queue length as an upper bound, 
call queue length is proportional to the number of handlers but not 
proportional to the number of clients in the system. Also one connection may 
have more than one requests in the call queue.

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

Reply via email to