You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@bookkeeper.apache.org by "Sijie Guo (JIRA)" <ji...@apache.org> on 2013/08/15 04:40:49 UTC

[jira] [Comment Edited] (BOOKKEEPER-654) Bookkeeper client operations are allowed even after its closure, bk#close()

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

Sijie Guo edited comment on BOOKKEEPER-654 at 8/15/13 2:40 AM:
---------------------------------------------------------------

{quote}
Actually I was trying to address a case where bookkeeper is closed and after this, when tries to do bk#asyncReadEntries, one should get clear Code.BkClientClosedException. How we could handle this case in PendingReadOP?, as bk.scheduler has shutdown and would throw exception.
{quote}

I don't understand as the speculative read doesn't change the read path. PendingReadOp would fail with BkClientClosedException after BookieClient is closed, no matter there is speculative read or not, isn't it? think about if user disables speculative read by setting speculativeReadTimeout to 0, the speculative read code will never be touched.

my comment was that we could catch exceptions but we don't need to callback with BKCloseException when catching exception on scheduling speculative reads. As I don't want to spread the callback over places, otherwise it is hard to debug and maintain.
                
      was (Author: hustlmsp):
    {quote}
Actually I was trying to address a case where bookkeeper is closed and after this, when tries to do bk#asyncReadEntries, one should get clear Code.BkClientClosedException. How we could handle this case in PendingReadOP?, as bk.scheduler has shutdown and would throw exception.
{quote}

I don't understand as the speculative read doesn't change the read path. PendingReadOp would fail with BkClientClosedException after BookieClient is closed, no matter there is speculative read or not, isn't it?

my comment was that we could catch exceptions but we don't need to callback with BKCloseException when catching exception on scheduling speculative reads. As I don't want to spread the callback over places, otherwise it is hard to debug and maintain.
                  
> Bookkeeper client operations are allowed even after its closure, bk#close()
> ---------------------------------------------------------------------------
>
>                 Key: BOOKKEEPER-654
>                 URL: https://issues.apache.org/jira/browse/BOOKKEEPER-654
>             Project: Bookkeeper
>          Issue Type: Bug
>          Components: bookkeeper-client
>    Affects Versions: 4.2.0
>            Reporter: Rakesh R
>            Assignee: Rakesh R
>             Fix For: 4.2.2, 4.3.0
>
>         Attachments: 0001-BOOKKEEPER-654-testcase-to-understand-more.patch, 0002-BOOKKEEPER-654.patch, 0003-BOOKKEEPER-654.patch, 0004-BOOKKEEPER-654.patch
>
>
> User can perform below operations with the closed bookkeeper client, which was instantiated with external zkclient.
> - open a closed ledger 
> - create a new ledger 
> Also, ledgerhandle operations like fencing/add/write are infinitely hanging.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira