[ 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)