[
https://issues.apache.org/jira/browse/HBASE-10357?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13997113#comment-13997113
]
Enis Soztutar commented on HBASE-10357:
---------------------------------------
bq. I think for 1.0 we should make the change that a table shouldn't be closed
if we want to invoke methods on that table.
Agreed. I think this is already a requirement.
bq. CellScanner, depending on cell block support from the client. For the
latter case, I think it was not straightforward to check whether something was
stale or not without introducing 'stale' notion in the Cell etc.
I see. I did not take a closer look into how cell blocks are results are
carried in rpc. If the Result objects for those are constructed at the
receiving side, then yes we should pass the staleness of those in the response
separately. I guess this change does it:
{code}
- results[i] = Result.create(cells);
+ results[i] = Result.create(cells, null, response.getStale());
{code}
If Result would have more fields in the future, then we have to ensure that
every field is also carried over at the ScanResponse. Other than passing in
empty Result objects with cellblocks in ScanResponse, adding the field there
makes sense. Just a note for future.
- Looked at how we are closing the scanners that did not return the result. We
are scheduling the close in the thread pool to be executed later. This should
be fine. If the close request comes while the actual scan is being executed (or
not scheduled yet) it will still be fine I guess. What happens if the scanner
is not opened yet (scannerId = -1). Can it happen that we try to close first,
then open the scanner?
- I think the printStackTrace() change is still in the patch.
- This is not needed? {{+import org.apache.hadoop.util.ReflectionUtils;}}
- Sorry, one thing I forgot to mention was that, whether or not we can make
the replicas transparent to the ClientScanner:
{code}
+ private boolean possiblyNextScanner(int nbRows, final boolean done) throws
IOException {
+ // If we have just switched replica, don't go to the next scanner yet.
Rather, try
+ // the scanner operations on the new replica.
+ if (callable != null && callable.switchedToADifferentReplica()) return
true;
+ return nextScanner(nbRows, done);
+ }
{code}
Conceptually, the RegionScanner should not leak that it is doing multi-rpc's to
the client scanner which controls the scanners for multiple regions. What do
you think?
> Failover RPC's for scans
> ------------------------
>
> Key: HBASE-10357
> URL: https://issues.apache.org/jira/browse/HBASE-10357
> Project: HBase
> Issue Type: Sub-task
> Components: Client
> Reporter: Enis Soztutar
> Fix For: 0.99.0, hbase-10070
>
> Attachments: 10357-1.txt, 10357-2.txt, 10357-3.2.txt, 10357-3.txt,
> 10357-4.2.txt, 10357-4.3.1.txt, 10357-4.3.txt, 10357-4.txt
>
>
> This is extension of HBASE-10355 to add failover support for scans.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
