hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sergey Shelukhin (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HBASE-10356) Failover RPC's for multi-get
Date Thu, 06 Feb 2014 17:54:10 GMT

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

Mime
View raw message