[
https://issues.apache.org/jira/browse/BOOKKEEPER-162?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13204323#comment-13204323
]
Sijie Guo commented on BOOKKEEPER-162:
--------------------------------------
thanks Flavio. most of the patch is good to me, except that you import
LedgerHandle in PerChannelBookieClient and BookKeeperTestClient in
BookieReadWriteTest, these two classes are not used, and in
ReadLastConfirmedOp.java why you don't use Math.max ?
> LedgerHandle.readLastConfirmed does not work
> --------------------------------------------
>
> Key: BOOKKEEPER-162
> URL: https://issues.apache.org/jira/browse/BOOKKEEPER-162
> Project: Bookkeeper
> Issue Type: Bug
> Components: bookkeeper-client
> Affects Versions: 4.0.0
> Reporter: Philipp Sushkin
> Assignee: Flavio Junqueira
> Priority: Critical
> Fix For: 4.1.0
>
> Attachments: BOOKKEEPER-162.patch, BOOKKEEPER-162.patch,
> BOOKKEEPER-162.patch, BOOKKEEPER-162.patch, BookieReadWriteTest.java.patch,
> BookieReadWriteTest.java.patch, BookieReadWriteTest.java.patch, bookkeeper.log
>
>
> Two bookkeeper clients.
> 1st continuously writing to ledger X.
> 2nd (bk.openLedgerNoRecovery) polling ledger X for new entries and reading
> them.
> In response we always reveiceing 0 as last confirmed entry id (in fact we are
> receiving -1 from each bookie RecoveryData but then in ReadLastConfirmedOp,
> but uninitialized "long maxAddConfirmed;" takes priority in Math.max(...).
> Main question - is given scenario is expected to work at all?
--
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
