[jira] [Commented] (BOOKKEEPER-458) Annoy BKReadException error when changing ledger.

["Flavio Junqueira (JIRA)" <ji...@apache.org>]

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

Flavio Junqueira commented on BOOKKEEPER-458:
---------------------------------------------

Hi Jiannan, I was wondering if you're planning on having a new patch uploaded soon.
                
> Annoy BKReadException error when changing ledger.
> -------------------------------------------------
>
>                 Key: BOOKKEEPER-458
>                 URL: https://issues.apache.org/jira/browse/BOOKKEEPER-458
>             Project: Bookkeeper
>          Issue Type: Bug
>          Components: hedwig-server
>            Reporter: Sijie Guo
>            Assignee: Jiannan Wang
>            Priority: Minor
>             Fix For: 4.2.0
>
>         Attachments: BOOKKEEPER-458.diff
>
>
> Some annoy BKReadException are found when changing ledger.
> 1) suppose Topic T has ledger L1, storing messages starting from 1 - 100.
> 2) T changed ledger to write entry to ledger L2.
> 3) Before the entry is added successfully, Subscribe s subscribed topic T. ReadAhead cache tried to schedule a ReadAhead request to scan (103, 104).
> 4) RangeScanOp in BookKeeperPersistentManager executed to read entry 2 & 3 from L2. but actually there was no entries in L2.
> {code:title=BookKeeperPersistentManager.java}
> // None of the old ledgers have this seq-id, we must use the
>                 // current ledger
>                 long endSeqId = topicInfo.currentLedgerRange.getStartSeqIdIncluded()
>                                 + topicInfo.lastEntryIdAckedInCurrentLedger;
>                 if (endSeqId < startSeqId) {
>                     request.getCallback().scanFinished(request.ctx, ReasonForFinish.NO_MORE_MESSAGES);                    return;
>                 }
> {code} 
> The code in BookKeeperPersistentManager is supposed to not scan any messages whose seq id is larger than lastEntryIdAckedInCurrentLedger. But lastEntryIdAckedInCurrentLedger isn't reset when changing ledger. so when RangeScanOp is executed, last entry id acked in previous ledger was used which causing calculating an error seq id for the boundary checking in RangeScanOp.
> The fix would be quite easy to reset lastEntryIdAckedInCurrentLedger when changing ledger. But we need a test case to cover this case.

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