You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@hbase.apache.org by "Ted Yu (JIRA)" <ji...@apache.org> on 2016/06/01 17:53:59 UTC

[jira] [Commented] (HBASE-15584) Revisit handling of BackupState#CANCELLED

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

Ted Yu commented on HBASE-15584:
--------------------------------

Recapping previous discussion from https://reviews.apache.org/r/45149/#comment189160​ :

From myself:
{quote}
HMaster#abortBackup() looks up the procedure Id by backup Id and aborts the procedure.

Using Future#cancel() is geared towards Java client.

After admin issues backup command (and receiving backupId), the backup process may be quite long. Another admin command (say through shell) would be used to cancel the backup. Since backupTables() API returns backupId to user, providing API to cancel by backupId is more user friendly.

The user can still list procedures and cancel the selected backup procedure.
{quote}
From Enis:
{quote}
if we save the procId in the BackupContext and do persist that in the system table before returning back to the client with the backupId, then the client API can accept abort(backupId) then it will look up backupId -> procId and call abort(procId). Just a suggestion.
{quote}
From Matteo:
{quote}
I still don't understand why we need two system that do the same thing. 
the procId does already what the backupId does. 
with the difference that we have already a mechanism to list the procedures in progress and abort them. and I don't see that for backup yet.

assume the case. your client dies before being able to recive the rpc response from the master or before being able to write the id. how do you look that up? with the procedure you can already do it. I don't see the point to write the same thing for backup and then have to do a reverse jump to abort the procedure when you ask to abort the backup
{quote}

> Revisit handling of BackupState#CANCELLED
> -----------------------------------------
>
>                 Key: HBASE-15584
>                 URL: https://issues.apache.org/jira/browse/HBASE-15584
>             Project: HBase
>          Issue Type: Sub-task
>            Reporter: Ted Yu
>            Priority: Minor
>
> During review of HBASE-15411, Enis made the following point:
> {code}
> nobody puts the backup in cancelled state. setCancelled() is not used. So if I abort a backup, who writes to the system table the new state? 
> Not sure whether this is a phase 1 patch issue or due to this patch. We can open a new jira and address it there if you do not want to do it in this patch. 
> Also maybe this should be named ABORTED rather than CANCELLED.
> {code}
> This issue is to decide whether this state should be kept (e.g. through notification from procedure V2 framework in response to abortion).
> If it is to be kept, the state should be renamed ABORTED.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)