[
https://issues.apache.org/jira/browse/HBASE-17174?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15721124#comment-15721124
]
Ted Yu commented on HBASE-17174:
--------------------------------
Consider renaming the variable below (e.g. naming it future or reqFuture):
{code}
+ AsyncRequestFuture empty = checkTask(task);
{code}
{code}
+ task.getCallback(), task.getResults(), task.getCallable(),
task.getRpcTimeout(), task.getOperationTimeout());
...
+ tableName, retainedActions, nonceGroup, pool, callback, results,
needResults, null, rpcTimeout, operationTimeout);
{code}
Wrap long line.
{code}
+ * @param rpcTimeout use the default value if the pssed timeout is smaller
than zero
...
+ private <CResult> AsyncRequestFuture submit(ExecutorService pool, TableName
tableName,
...
+ boolean needResults, int rpcTimeout, int operationTimeout) throws
InterruptedIOException {
{code}
Please add @param for operationTimeout.
For AsyncProcessTask, please add class javadoc.
{code}
+ public enum SubmittedSize {
+ ALL, AT_LEAST_ONE, NORMAL
{code}
Add javadoc for each of the enum.
What's the unit for AT_LEAST_ONE (since the enum talks about size) ?
{code}
+ private AsyncProcess createAsyncProcess(boolean useGlobalErrors) {
{code}
Can the above method be folded into createAsyncProcess() ?
{code}
+ //TODO: Any better timeout value?
+ batch(actions, results, Math.max(readRpcTimeout, writeRpcTimeout));
{code}
Probably iterate through the actions and set to writeRpcTimeout if there are
both read and write actions.
Otherwise use the corresponding timeout.
> Use shared threadpool and AsyncProcess in BufferedMutatorImpl
> -------------------------------------------------------------
>
> Key: HBASE-17174
> URL: https://issues.apache.org/jira/browse/HBASE-17174
> Project: HBase
> Issue Type: New Feature
> Affects Versions: 2.0.0
> Reporter: ChiaPing Tsai
> Assignee: ChiaPing Tsai
> Priority: Minor
> Fix For: 2.0.0
>
> Attachments: HBASE-17174.v0.patch, HBASE-17174.v1.patch,
> HBASE-17174.v2.patch, HBASE-17174.v3.patch, HBASE-17174.v4.patch,
> HBASE-17174.v5.patch, HBASE-17174.v6.patch, HBASE-17174.v7.patch
>
>
> The following are reasons of reusing the pool and AP.
> # A update-heavy application, for example, loader, creates many
> BufferedMutator for batch updates. But these BufferedMutators can’t share a
> large threadpool because the shutdown() method will be called when closing
> any BufferedMutator. This patch adds a flag into BufferedMutatorParams for
> preventing calling the shutdown() method in BufferedMutatorImpl#close
> # The AsyncProcess has the powerful traffic control, but the control is
> against the single table currently. Because the AP is constructed at
> BufferedMutatorImpl's construction. This patch change the
> BufferedMutatorImpl's construction for reuse the AP so that the updates for
> different tables can be restricted by the same AP.
> Additionally, there are two changes(aren't included in latest patch) for #2.
> 1) The AP will be exposed to user.
> 2) A new method will be added to Connection for instantiating a AP.
> All suggestions are welcome.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
