[
https://issues.apache.org/jira/browse/HBASE-8836?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13696232#comment-13696232
]
Ted Yu commented on HBASE-8836:
-------------------------------
{code}
+ if (action instanceof Delete || action instanceof Put ||
action instanceof Increment
+ || action instanceof Append || action instanceof
RowMutations) {
...
+ if (methodName.contains("put") || methodName.contains("mutate") ||
methodName.contains("increment")
+ || methodName.contains("delete"))
{code}
Is append missing from the second if statement above ?
{code}
- return getServer(instance.getClass(), instance, ifaces, bindAddress, port,
numHandlers, metaHandlerCount, verbose, conf, highPriorityLevel);
+ return getServer(instance.getClass(), instance, ifaces, bindAddress, port,
numHandlers, metaHandlerCount, readerHandlerCount, verbose, conf,
highPriorityLevel);
}
{code}
Wrap long line.
{code}
+ this.readCallQueue = new LinkedBlockingQueue<Call>(maxQueueLength);
{code}
Should reader queue have its own max length ?
SecureServer extends HBaseServer. As Lars said, code duplication should be
minimized.
> Separate reader and writer thread pool in RegionServer, so that write
> throughput will not be impacted when the read load is very high
> -------------------------------------------------------------------------------------------------------------------------------------
>
> Key: HBASE-8836
> URL: https://issues.apache.org/jira/browse/HBASE-8836
> Project: HBase
> Issue Type: New Feature
> Components: Performance, regionserver
> Affects Versions: 0.94.8
> Reporter: Tianying Chang
> Assignee: Tianying Chang
> Fix For: 0.98.0, 0.95.2, 0.94.10
>
> Attachments: hbase-8836.patch
>
>
> We found that when the read load on a specific RS is high, the write
> throughput also get impacted dramatically, and even cause write data loss
> sometimes. We want to prioritize the write by putting them in a separate
> queue from the read request, so that slower read will not make fast write
> wait nu-necessarily long.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
