[
https://issues.apache.org/jira/browse/BOOKKEEPER-1019?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15945292#comment-15945292
]
Enrico Olivelli commented on BOOKKEEPER-1019:
---------------------------------------------
I think that the only issue may rise in case of writer crash without
piggybacking the LAC or closing the LedgerHandle, in this case another client
may recover the ledger and truncate the ledger at the last add confirmed sent
to the bookie, but I'm not sure.
> Support for reading entries after LAC (causal consistency driven by
> out-of-band communications)
> -----------------------------------------------------------------------------------------------
>
> Key: BOOKKEEPER-1019
> URL: https://issues.apache.org/jira/browse/BOOKKEEPER-1019
> Project: Bookkeeper
> Issue Type: New Feature
> Components: bookkeeper-client
> Affects Versions: 4.4.0
> Reporter: Enrico Olivelli
> Assignee: Enrico Olivelli
> Fix For: 4.5.0
>
>
> Currently we check in asyncReadEntries that the range of entries is within
> the range 0....LastAddConfirmed.
> This is because the LAC guarantees that the client can read only entries that
> have been acked from the writer.
> The LAC protocol is very useful when there is not direct communication
> between "writers" and "readers".
> I have an use case in which the "writer" blocks until the write is acked
> (like addEntry) and then it takes the returned id (ledgerId + entryid) and
> passes it to a "reader" which in turn tries to read the entry.
> This communication is done out-of-band in respect to BookKeeper and we can
> assume that the entries has been stored in a durable way (the write as been
> acked by a quorum of bookies).
> As the 'reader' as received a confirmation the the writer as successifully
> written the entry it can read it without waiting for the piggyback of the LAC
> of the standard bookkeeper protocol.
> This is the normal way of working with transactional databases or with
> filesystems.
> This is kind of "causal consistency".
> The idea is to add a configuration option to relax the check in
> asyncreadEntries
> this is 4.4 version:
> {code}
> if (lastEntry > lastAddConfirmed) {
> LOG.error("ReadException on ledgerId:{} firstEntry:{}
> lastEntry:{}",
> new Object[] { ledgerId, firstEntry, lastEntry });
> cb.readComplete(BKException.Code.ReadException, this, null, ctx);
> return;
> }
> {code}
> this is my proposal:
> {code}
> if (lastEntry > lastAddConfirmed &&
> !allowReadingAfterLastAddConfirmed) {
> LOG.error("ReadException on ledgerId:{} firstEntry:{}
> lastEntry:{}",
> new Object[] { ledgerId, firstEntry, lastEntry });
> cb.readComplete(BKException.Code.ReadException, this, null, ctx);
> return;
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
