[
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.
Right..
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, 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)
