[
https://issues.apache.org/jira/browse/HBASE-10356?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13893583#comment-13893583
]
Sergey Shelukhin commented on HBASE-10356:
------------------------------------------
bq. Why does Action have to know about replicaid? Currently it is the outline
of a Get, Put, or Delete just for keeping up an index so we can run multi of
these in a request... and make sense of the result and exceptoins when they
come back. replicaid stuff should be going on elsewhere where we are figuring
the destination server for this Action? Won't you want to be able to take an
Action that fails one replica and point it at another replica (w/o having to
update the replica it is carrying?)
Action represents local context for a particular... action (which is different
from Action, hence action.getAction(), poor naming imho) that is a part of
MultiAction. Local context included original index, now it also includes
replica ID for the same reason, it needs to be propagated between sending
request and processing response (not going to server, though). Seems like a
logical place to put it.
bq. On AsyncProcess knowing about replicas, again, shouldn't it be a read
replica driver class that runs the AsyncProcess making sense of results and
rescheduling against new replicas if failure rather than doctoring of
AsyncProcess?
First, replica calls run in parallel with normal calls, it's not just for
failures, so there has to be a point of syncronization. Second, AP currently
already manages finding the locations and grouping of request, it wouldn't make
sense to have another external place to manage replica locations separately and
group requests separately for replica case. If you notice, the send code is
almost the same replicas or no replicas, the only difference is how we group,
and the scheduling of replica calls themselves.
bq. Its hard to figure how this works. Is there a bit of doc on it somewhere?
I will augment the comments :)
bq. A AsyncRequestFutureImpl has a ReplicaRunnable. What is a ReplicaRunnable?
bq. SingleServerRunnable is what happens when no read replicas? Why ain't
SingleServerRunnable an instance of ReplicaRunnable only replicas==1?
Both are just thread runnables; the second is just moved code - previously it
was an inline runnable for calls, I moved it to make code cleaner.
The first is a runnable for replica calls thread. Replica calls could be made
on the same thread, but that would compromise the async behavior because we
wait before making them.
> Failover RPC's for multi-get
> -----------------------------
>
> Key: HBASE-10356
> URL: https://issues.apache.org/jira/browse/HBASE-10356
> Project: HBase
> Issue Type: Sub-task
> Components: Client
> Reporter: Enis Soztutar
> Assignee: Sergey Shelukhin
> Fix For: 0.99.0
>
> Attachments: HBASE-10356.reference.patch, HBASE-10356.reference.patch
>
>
> This is extension of HBASE-10355 to add failover support for multi-gets.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
