[
https://issues.apache.org/jira/browse/HBASE-15146?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15343958#comment-15343958
]
Elliott Clark commented on HBASE-15146:
---------------------------------------
bq.That seems based on the fact that there are some clients which don't wait
the response of the previously sent request
Nope, it's all about pushing back before blocking on queueing things that can't
be answered in a reasonable time. You can get the queue full with enough single
clients.
The reader is non-blocking. The fact that we were blocking and not acking tcp
streams until after full requests are completed was not a preformance benefit
in any way. It was just wrong. It lost perf in multiple different ways.
To see this in the extreme set the handlers to one, and the call queue length
to one. Then tcpdump and see what happens.
> Don't block on Reader threads queueing to a scheduler queue
> -----------------------------------------------------------
>
> Key: HBASE-15146
> URL: https://issues.apache.org/jira/browse/HBASE-15146
> Project: HBase
> Issue Type: Bug
> Affects Versions: 1.2.0
> Reporter: Elliott Clark
> Assignee: Elliott Clark
> Priority: Blocker
> Fix For: 2.0.0, 1.2.0, 1.3.0
>
> Attachments: HBASE-15146-v7.patch, HBASE-15146-v8.patch,
> HBASE-15146-v8.patch, HBASE-15146.0.patch, HBASE-15146.1.patch,
> HBASE-15146.2.patch, HBASE-15146.3.patch, HBASE-15146.4.patch,
> HBASE-15146.5.patch, HBASE-15146.6.patch
>
>
> Blocking on the epoll thread is awful. The new rpc scheduler can have lots of
> different queues. Those queues have different capacity limits. Currently the
> dispatch method can block trying to add the the blocking queue in any of the
> schedulers.
> This causes readers to block, tcp acks are delayed, and everything slows down.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
