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