[
https://issues.apache.org/jira/browse/HBASE-14331?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14738022#comment-14738022
]
Hiroshi Ikeda commented on HBASE-14331:
---------------------------------------
bq. So will this SempahoreBasedQueue allow me to extend its implementation to
have a round robin mode?
Do you mean SemaphoreBasedQueue should be public?
The interface {{CallQueue}} is extracted from the current implementation
classes in order to replace the internal queue, and the methods of the
interface are just prepared for it. I think this interface is not enough for
other uses and its naming is a bit rough and vague, and I created it as
package-private as you can change it as necessary.
It would be better to create CAS based bounded FIFO/priority {{BlockingQueue}},
but it is difficult for me. Actually Java7 introduces the class
{{LinkedTransferQueue}}, which is CAS based *unbounded* FIFO {{BlockingQueue}},
and it might be possible to create other ones by imitating its logic, or in
future Java might introduce them.
With respect to RpcScheduler, do you mean it would be useful to use round robin
for multiplexed queues instead of random selection? I believe that it is the
best to use a single CAS queue (unless you change the logic of handling
requests by their priority). HBASE-11355 introduced multiplexed queue and
improved performance, but I think it is just sort of lock striping for lock
based queues, and it went the wrong way.
> a single callQueue related improvements
> ---------------------------------------
>
> Key: HBASE-14331
> URL: https://issues.apache.org/jira/browse/HBASE-14331
> Project: HBase
> Issue Type: Improvement
> Components: IPC/RPC, Performance
> Reporter: Hiroshi Ikeda
> Assignee: Hiroshi Ikeda
> Priority: Minor
> Attachments: BlockingQueuesPerformanceTestApp-output.pdf,
> BlockingQueuesPerformanceTestApp-output.txt,
> BlockingQueuesPerformanceTestApp.java, CallQueuePerformanceTestApp.java,
> HBASE-14331-V2.patch, HBASE-14331.patch, HBASE-14331.patch,
> SemaphoreBasedBlockingQueue.java, SemaphoreBasedLinkedBlockingQueue.java,
> SemaphoreBasedPriorityBlockingQueue.java
>
>
> {{LinkedBlockingQueue}} well separates locks between the {{take}} method and
> the {{put}} method, but not between takers, and not between putters. These
> methods are implemented to take locks at the almost beginning of their logic.
> HBASE-11355 introduces multiple call-queues to reduce such possible
> congestion, but I doubt that it is required to stick to {{BlockingQueue}}.
> There are the other shortcomings of using {{BlockingQueue}}. When using
> multiple queues, since {{BlockingQueue}} blocks threads it is required to
> prepare enough threads for each queue. It is possible that there is a queue
> starving for threads while there is another queue where threads are idle.
> Even if you can tune parameters to avoid such situations, the tuning is not
> so trivial.
> I suggest using a single {{ConcurrentLinkedQueue}} with {{Semaphore}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
