Mailing-List: contact core-dev-help@hadoop.apache.org; run by ezmlm
Precedence: bulk
Reply-To: core-dev@hadoop.apache.org
Message-ID: <1954788440.1205877864535.JavaMail.jira@brutus>
Date: Tue, 18 Mar 2008 15:04:24 -0700 (PDT)
From: "Doug Cutting (JIRA)" <jira@apache.org>
To: core-dev@hadoop.apache.org
Subject: [jira] Commented: (HADOOP-2910) Throttle IPC Client/Server during
 bursts of requests or server slowdown
In-Reply-To: <1655129481.1204139511113.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

Doug Cutting commented on HADOOP-2910:
--------------------------------------

> Or we could have another thread that accepts connections. So it won't block when the call queue is full.

Yes, we could, and that would need to block when there are too many connections.  I think it might be simpler to only block on the call queue and remove the connect timeout.  The difference is just whether clients making calls when the queue is full get blocked in connect() or in write() -- either way, such clients will be blocked until the call queue is smaller.  So I don't think we do much better with a separate thread.

> 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.17.0
>
>         Attachments: callQueue.patch, callQueue1.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.