You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@bookkeeper.apache.org by "Uma Maheswara Rao G (JIRA)" <ji...@apache.org> on 2012/05/30 03:29:23 UTC

[jira] [Commented] (BOOKKEEPER-273) LedgerHandle.deleteLedger() should be idempotent

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

Uma Maheswara Rao G commented on BOOKKEEPER-273:
------------------------------------------------


I agree the case. Even normal file system also will not throw any exceptions on delete failures, but it will indicate with false about the opeation status.
Unfortunately deleteLedger is void API. But this will be a behaviour change, So, let's discuss with Ivan/Flavio. Existing customers might have the opinion of throwing exception when NoNode also. If the change approves, you may want to add test for this behavior... .Alternatively, can we set a different exception code in this case?
                
> LedgerHandle.deleteLedger() should be idempotent
> ------------------------------------------------
>
>                 Key: BOOKKEEPER-273
>                 URL: https://issues.apache.org/jira/browse/BOOKKEEPER-273
>             Project: Bookkeeper
>          Issue Type: Bug
>          Components: bookkeeper-client
>    Affects Versions: 4.1.0
>            Reporter: Matteo Merli
>            Priority: Minor
>             Fix For: 4.1.0
>
>         Attachments: 0001-BOOKKEEPER-273-LedgerHandle.deleteLedger-should-be-i.patch
>
>
> Deleting a non-existing ledger should silently succeed. 
> Current behavior is to raise a ZKException, but it's not possible to know whether there was some error or the ledger does not exists anymore. 
> This scenario will happen when a previous deleteLedger() call succeeded but the client crashed before updating its own ledger list.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira