[
https://issues.apache.org/jira/browse/HBASE-15584?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15294378#comment-15294378
]
Matteo Bertozzi commented on HBASE-15584:
-----------------------------------------
what does it mean not user friendly what were they trying to do?
the current approach is the usual "task manager approach"
- you start backup
- your client crash
- you list what was in progress
- and you abort what you think you need to abort
I don't think there is a much more user friendly way unless you want to add a
wal on the client side.
to resume from where you where and give you back the instance of your object.
if your client isn't crashed then you can just call future.abort(), so the
problem is only when the client crash
> 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)
