Mailing-List: contact issues-help@hbase.apache.org; run by ezmlm
Precedence: bulk
Date: Thu, 6 Feb 2014 17:54:10 +0000 (UTC)
From: "Sergey Shelukhin (JIRA)" <jira@apache.org>
To: issues@hbase.apache.org
Message-ID: <JIRA.12689127.1389830909681.49940.1391709250028@arcas>
In-Reply-To: <JIRA.12689127.1389830909681@arcas>
References: <JIRA.12689127.1389830909681@arcas>
Subject: [jira] [Commented] (HBASE-10356) Failover RPC's for multi-get
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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