[
https://issues.apache.org/jira/browse/HBASE-15921?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15515674#comment-15515674
]
Yu Li commented on HBASE-15921:
-------------------------------
Generally, +1 on do retry at one place and have an operation timeout for the
whole operation.
Specially, I think we should discuss about single, batch and scan request
separately, when talking about "always restart from beginning":
1. For single request like Get/Mutation(Put/Append/Increment/Delete), yes each
retry should start from beginning
2. For batch request, assume we will still group the actions into RS groups, I
think the retry should be per-group level, rather than all restart from
beginning on one group failure
3. For (the real, multiple rows, not Get) scan request, assume we still keep
recording {{nextCallSeqId}}, we should restart from it rather than from the
very beginning
Or please let me know if you meant something else for "always restart from
beginning". Thanks.
> Add first AsyncTable impl and create TableImpl based on it
> ----------------------------------------------------------
>
> Key: HBASE-15921
> URL: https://issues.apache.org/jira/browse/HBASE-15921
> Project: HBase
> Issue Type: Improvement
> Affects Versions: 2.0.0
> Reporter: Jurriaan Mous
> Assignee: Duo Zhang
> Fix For: 2.0.0
>
> Attachments: HBASE-15921-v2.patch, HBASE-15921.demo.patch,
> HBASE-15921.patch, HBASE-15921.v1.patch
>
>
> First we create an AsyncTable interface with implementation without the Scan
> functionality. Those will land in a separate patch since they need a refactor
> of existing scans.
> Also added is a new TableImpl to replace HTable. It uses the AsyncTableImpl
> internally and should be a bit faster because it does jump through less hoops
> to do ProtoBuf transportation. This way we can run all existing tests on the
> AsyncTableImpl to guarantee its quality.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
