[
https://issues.apache.org/jira/browse/HBASE-14479?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14954386#comment-14954386
]
Hiroshi Ikeda commented on HBASE-14479:
---------------------------------------
Sorry I have little time now so response a few comments.
{quote}
+ There is only one Reader thread so how can there be leaders and followers?
+ If only one Reader thread, could we discard and let the Listener thread do
the dispatch?
{quote}
{{Reader}} is a just runnable task and not extending {{Thread}}.
Threads are created in a thread pool (It seems a strange usage but I want to
put it aside for now).
{quote}
+ SelectionKey key = selectedKeyQueue.poll();
+ if (key != null)
{ + processing(key); + continue; + }
{quote}
That intends just event dispatching while {{key}} != null (corresponding to the
transition following->processing), and the semaphore releases threads so that
the only one thread encounters {{key}} == null and promotes to the leader
(following->leading).
> Apply the Leader/Followers pattern to RpcServer's Reader
> --------------------------------------------------------
>
> Key: HBASE-14479
> URL: https://issues.apache.org/jira/browse/HBASE-14479
> Project: HBase
> Issue Type: Improvement
> Components: IPC/RPC, Performance
> Reporter: Hiroshi Ikeda
> Assignee: Hiroshi Ikeda
> Priority: Minor
> Attachments: HBASE-14479-V2 (1).patch, HBASE-14479-V2.patch,
> HBASE-14479-V2.patch, HBASE-14479.patch, gc.png, gets.png, io.png, median.png
>
>
> {{RpcServer}} uses multiple selectors to read data for load distribution, but
> the distribution is just done by round-robin. It is uncertain, especially for
> long run, whether load is equally divided and resources are used without
> being wasted.
> Moreover, multiple selectors may cause excessive context switches which give
> priority to low latency (while we just add the requests to queues), and it is
> possible to reduce throughput of the whole server.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
