[
https://issues.apache.org/jira/browse/BOOKKEEPER-623?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13680986#comment-13680986
]
Uma Maheswara Rao G commented on BOOKKEEPER-623:
------------------------------------------------
>From Vinay Analysis: When we get failure response from one BK, we are changing
>the ensemble unconditionally, whther that is already closed or not. He is
>adding closed check in BK failure call back also.
I think locks should be consistent as current close check is under metadata
lock and where asyncCloseInternal works under LedgerHandle lock.
> Metadata is having extra Segment which is causing AutoRecovery to fail
> ----------------------------------------------------------------------
>
> Key: BOOKKEEPER-623
> URL: https://issues.apache.org/jira/browse/BOOKKEEPER-623
> Project: Bookkeeper
> Issue Type: Bug
> Components: bookkeeper-server
> Affects Versions: 4.2.1, 4.3.0
> Reporter: Vinay
> Assignee: Vinay
> Fix For: 4.3.0
>
> Attachments: BOOKKEEPER-623.patch
>
>
> With the almost same testcase mentioned in the BOOKKEEPER-584, Ledger
> metadata is getting added with extra segment during failure handling of
> bookies along with fencing.
> Only difference in the testcase is .
> 1. Before bookie failures some entries were already written
> 2. And after bookies failed ( First bookie will throw
> LedgerFenced/Unauthorized exception, and second bookie is slow/dead bookie ),
> Number of entries written asynchrounously is n*ensembleSize+1
> Note that, Unauthorized/FencedException callback comes first, then other
> bookie failure callback comes.
> I will attach a TestCase along with patch for this shortly. Testcase is
> modified version of attached testcase in BOOKKEEPER-584
--
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
