hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Enis Soztutar (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HBASE-10357) Failover RPC's for scans
Date Wed, 14 May 2014 00:39:16 GMT

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

Mime
View raw message