On Tue, Mar 28, 2017 at 11:21 AM, Enrico Olivelli <eolive...@gmail.com> wrote:
> Il mar 28 mar 2017, 17:45 Venkateswara Rao Jujjuri <jujj...@gmail.com> ha > scritto: > > > 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. > > > > JV, > I am working to a new project that is essentialy a distributed large object > store, like you are doing at SF. > I am currently using the explicit LAC with I was waiting for long time. > After some benchs me and my colleagues start thinking if there was another > way to achieve the same goal and maybe using less resources. > In my project a client writes an object and only once the write has been > acknowledged the object is considered published on the store. So it must be > readable immediately by other clients. > Is reader running in the same process with the writer? what semantics are you going to achieve? read-my-write? > As the coordination in this case is already done from other services > external to BookKeeper the LAC is not very useful IMHO and so maybe we can > just simply skip the check. > > I wonder if this can have some issues > > I am going to release the project as open-source as soon as the alpha > version will be usable, so that I can share the code and diaccuss better > with the community > > > > 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 > > > -- > > > -- Enrico Olivelli >
