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