We have Explicit LAC updates now, and I recall you have made it more
granular (milli seconds)
given that, I am just wondering the need of your out of band communication
and taking an alternate route
in the client code.

Thanks,
JV

On Tue, Mar 28, 2017 at 7:36 AM, Enrico Olivelli <eolive...@gmail.com>
wrote:

> Hi all,
> I have just created this issue about a new small "feature"
> https://issues.apache.org/jira/browse/BOOKKEEPER-1019.
>
> The patch is very simple and I wonder if I am missing something.
>
> I'm copying the description of the issue in this email in order to start
> some discussion
>
> 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:
>
>         if (lastEntry > lastAddConfirmed) {
>             LOG.error("ReadException on ledgerId:{} firstEntry:{}
> lastEntry:{}",
>                     new Object[] { ledgerId, firstEntry, lastEntry });
>             cb.readComplete(BKException.Code.ReadException, this, null,
> ctx);
>             return;
>         }
>
> this is my proposal:
>
>         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;
>         }
>
>
> Does this make sense to any of you ?
>
> Enrico
>



-- 
Jvrao
---
First they ignore you, then they laugh at you, then they fight you, then
you win. - Mahatma Gandhi

Reply via email to