[
https://issues.apache.org/jira/browse/HBASE-15146?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15111785#comment-15111785
]
Gary Helmling commented on HBASE-15146:
---------------------------------------
In AsyncProcess$AsyncRequestFutureImpl.receiveGlobalFailure(), we don't pass
along the Throwable when calling updateCachedLocations(). Still looking into
where receiveGlobalFailure() is called from, but I'm concerned this could be
another hole for clearing meta cache, while could cause some unnecessary load
re-scanning meta. Seems like we need closer checking of the multi-action
results, so that if we _only_ get non-cache busting exception(s), then we pass
that along to updateCacheLocations so we don't unnecessarily clear.
We can drop the IllegalStateExceptions that were previously added to method
signatures, since we're now using offer() on the queue.
FifoRpcScheduler needs to decrement queueSize in the runnable that is submitted.
> 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: 1.2.0
>
> Attachments: HBASE-15146.0.patch, HBASE-15146.1.patch,
> HBASE-15146.2.patch, HBASE-15146.3.patch, HBASE-15146.4.patch,
> HBASE-15146.5.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)
