[
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
