[jira] [Commented] (BOOKKEEPER-1019) Support for reading entries after LAC (causal consistency driven by out-of-band communications)

["ASF GitHub Bot (JIRA)" <ji...@apache.org>]

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

ASF GitHub Bot commented on BOOKKEEPER-1019:
--------------------------------------------

Github user sijie commented on the issue:

    https://github.com/apache/bookkeeper/pull/121
  
    @merlimat do you mind taking a look at this one?


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