Mailing-List: contact issues-help@hbase.apache.org; run by ezmlm
Precedence: bulk
Date: Thu, 24 Jan 2013 20:37:14 +0000 (UTC)
From: "stack (JIRA)" <jira@apache.org>
To: issues@hbase.apache.org
Message-ID: <JIRA.12625731.1357163333391.186568.1359059834088@arcas>
In-Reply-To: <JIRA.12625731.1357163333391@arcas>
References: <JIRA.12625731.1357163333391@arcas>
Subject: [jira] [Commented] (HBASE-7478) Create a multi-threaded responder
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/HBASE-7478?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13561964#comment-13561964 ] 

stack commented on HBASE-7478:
------------------------------

Yeah, single responder thread only created up in Responder.  Looking at a site yesterday, saw pile up on the synchronize in the Responder#doRespond:

{code}
    void doRespond(Call call) throws IOException {
      // set the serve time when the response has to be sent later
      call.timestamp = System.currentTimeMillis();

      boolean doRegister = false;
      synchronized (call.connection.responseQueue) {
        call.connection.responseQueue.addLast(call);
        if (call.connection.responseQueue.size() == 1) {
          doRegister = !processResponse(call.connection.responseQueue, false);
        }
      }
      if (doRegister) {
        enqueueInSelector(call);
      }
    }
{code}

As I read it, we have pile up because all trying to respond to same client... so wonder if we will just move bottleneck to mutex'ing over the wire and rather, we should have more than one connection from client to server (as has been said elsewhere)
                
> Create a multi-threaded responder
> ---------------------------------
>
>                 Key: HBASE-7478
>                 URL: https://issues.apache.org/jira/browse/HBASE-7478
>             Project: HBase
>          Issue Type: Sub-task
>            Reporter: Karthik Ranganathan
>
> Currently, we have multi-threaded readers and handlers, but a single threaded responder which is a bottleneck.
> ipc.server.reader.count  : number of reader threads to read data off the wire
> ipc.server.handler.count : number of handler threads that process the request
> We need to have the ability to specify a "ipc.server.responder.count" to be able to specify the number of responder threads.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira