You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@bookkeeper.apache.org by "Flavio Junqueira (Commented) (JIRA)" <ji...@apache.org> on 2012/02/07 07:14:59 UTC
[jira] [Commented] (BOOKKEEPER-162) LedgerHandle.readLastConfirmed
does not work
[ https://issues.apache.org/jira/browse/BOOKKEEPER-162?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13202106#comment-13202106 ]
Flavio Junqueira commented on BOOKKEEPER-162:
---------------------------------------------
Hi Philipp, Are the adds to the ledger asynchronous? Are you calling readLastConfirmed after receiving an ack for some add operation?
In principle, it should work. Check testReadFromOpenLedger in BookieReadWriteTest.
Do you have logs you can share with us, both bookie and client?
> 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
> Priority: Critical
>
> 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