hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Devaraj Das (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HBASE-10357) Failover RPC's for scans
Date Sat, 10 May 2014 21:59:00 GMT

    [ https://issues.apache.org/jira/browse/HBASE-10357?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13993935#comment-13993935

Devaraj Das commented on HBASE-10357:

bq. SmallScannerCallable looks good. Does it have to extend ScannerCallable? Previously it
extended RegionServerCallable.

Yes this is required because the ScannerCallableWithReplicas takes a ScannerCallable in the
current patch.

bq. ClusterConnectionWithReplicaId seems unnecessary. If we need those methods in UT context,
it should be ok to make ClusterConnection public, but with explicit annotation that it is
a hbase-private interface.

Yeah, I thought about that as well. I don't have any strong opinion on this and will update
to have these methods in the ClusterConnection class.

bq.  it is breaking the callable pattern? Should we name it ScannerRetyingCallerWithReplicas
(similar to RpcRetryingCallerWithReadReplicas) and not implement a callable? 

In my opinion, this is okay. The reason being that the upper layers can remain unchanged -
they still see the callable, and, the same code is used for both timeline/strong.

bq. scanners other than the ones we hear back -> should be only one scanner, no?

Yes, we hear back from one scanner but we could have started the RPCs with multiple.

bq. Will there be any case where our passed pool is null? If we construct a new pool via HTable.getDefaultExecutor(conf),
how does it get shutdown ?

Yes, the pool can be null - for example the MetaScan methods don't invoke HTable constructors
that create a pool internally. But yeah, you have a valid point - I should close the pool
if i created it internally here.

bq. cs.take() cannot return null.


bq. When we have a response, how does the other scanners get closed. The CS will interrupt,
but those scanners might have already finished.

Yeah, I need to handle this case.

bq. Why are we adding another stale field in message ScanResponse? Every Result object already
contains this info over the wire, right?

There are two ways of returning the response. Result[] or 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. Wanted
to avoid all that and adding the stale in ScanResponse seemed logical. [look at the changes
in ResponseConverter where i use the ScanResponse.getStale()].

> 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
>         Attachments: 10357-1.txt, 10357-2.txt, 10357-3.2.txt, 10357-3.txt, 10357-4.2.txt,
> This is extension of HBASE-10355 to add failover support for scans. 

This message was sent by Atlassian JIRA

View raw message