You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@bookkeeper.apache.org by Enrico Olivelli <eo...@gmail.com> on 2018/07/10 08:11:29 UTC
[DISCUSS] ExplicitLAC on the reader's side
Hi,
Now that Charan is working on making ExplicitLAC persistent I would like to
start the discussion about merging the reader side view of LAC (ExplicitLAC
+ Pibbybacked/regular LAC)
Major points:
- Now (4.8) ExplicitLAC is to be read with LedgerHandle#readExplicitLAC
- ExplicitLAC is stored on LedgerStorage
- Regular LAC is stored inside each entry
- We have to support Long Poll
- We have to give access to ExplicitLAC on the new API (but I don't want to
add a readExplicitLAC on the new API)
- ExplicitLAC on the write side is only a matter of configuring the
scheduler, no changes are to be done on application code
Desiderata (from me):
The reader only uses Long-Poll or ReadHandle#readLastAddConfirmed and
transparently it receives the most accurate information from ExplicitLAC
and PiggyBacked LAC
In order to achieve this goal we will have to work on many parts, this is
my list:
- add current ExplicitLAC on readResponses
- merge ExplicitLAC and regular LAC on client side
- support watches for Long-Poll on Bookie side, to be triggered by
ExplicitLAC
Enrico
Re: [DISCUSS] ExplicitLAC on the reader's side
Posted by Enrico Olivelli <eo...@gmail.com>.
Cool,
I think this will be one big feature for 4.9, we will have time for design
discussion.
Not sure we can have something for 4.8, apart from persistent ExplicitLAC.
Enrico
Il mar 10 lug 2018, 18:40 Sijie Guo <gu...@gmail.com> ha scritto:
> +1
>
> On Tue, Jul 10, 2018 at 1:11 AM Enrico Olivelli <eo...@gmail.com>
> wrote:
>
> > Hi,
> > Now that Charan is working on making ExplicitLAC persistent I would like
> to
> > start the discussion about merging the reader side view of LAC
> (ExplicitLAC
> > + Pibbybacked/regular LAC)
> >
> > Major points:
> > - Now (4.8) ExplicitLAC is to be read with LedgerHandle#readExplicitLAC
> > - ExplicitLAC is stored on LedgerStorage
> > - Regular LAC is stored inside each entry
> > - We have to support Long Poll
> > - We have to give access to ExplicitLAC on the new API (but I don't want
> to
> > add a readExplicitLAC on the new API)
> > - ExplicitLAC on the write side is only a matter of configuring the
> > scheduler, no changes are to be done on application code
> >
> > Desiderata (from me):
> >
> > The reader only uses Long-Poll or ReadHandle#readLastAddConfirmed and
> > transparently it receives the most accurate information from ExplicitLAC
> > and PiggyBacked LAC
> >
> > In order to achieve this goal we will have to work on many parts, this is
> > my list:
> > - add current ExplicitLAC on readResponses
> > - merge ExplicitLAC and regular LAC on client side
> > - support watches for Long-Poll on Bookie side, to be triggered by
> > ExplicitLAC
> >
> >
> > Enrico
> >
>
--
-- Enrico Olivelli
Re: [DISCUSS] ExplicitLAC on the reader's side
Posted by Sijie Guo <gu...@gmail.com>.
+1
On Tue, Jul 10, 2018 at 1:11 AM Enrico Olivelli <eo...@gmail.com> wrote:
> Hi,
> Now that Charan is working on making ExplicitLAC persistent I would like to
> start the discussion about merging the reader side view of LAC (ExplicitLAC
> + Pibbybacked/regular LAC)
>
> Major points:
> - Now (4.8) ExplicitLAC is to be read with LedgerHandle#readExplicitLAC
> - ExplicitLAC is stored on LedgerStorage
> - Regular LAC is stored inside each entry
> - We have to support Long Poll
> - We have to give access to ExplicitLAC on the new API (but I don't want to
> add a readExplicitLAC on the new API)
> - ExplicitLAC on the write side is only a matter of configuring the
> scheduler, no changes are to be done on application code
>
> Desiderata (from me):
>
> The reader only uses Long-Poll or ReadHandle#readLastAddConfirmed and
> transparently it receives the most accurate information from ExplicitLAC
> and PiggyBacked LAC
>
> In order to achieve this goal we will have to work on many parts, this is
> my list:
> - add current ExplicitLAC on readResponses
> - merge ExplicitLAC and regular LAC on client side
> - support watches for Long-Poll on Bookie side, to be triggered by
> ExplicitLAC
>
>
> Enrico
>
Re: [DISCUSS] ExplicitLAC on the reader's side
Posted by Venkateswara Rao Jujjuri <ju...@gmail.com>.
+1
On Tue, Jul 10, 2018 at 1:11 AM, Enrico Olivelli <eo...@gmail.com>
wrote:
> Hi,
> Now that Charan is working on making ExplicitLAC persistent I would like to
> start the discussion about merging the reader side view of LAC (ExplicitLAC
> + Pibbybacked/regular LAC)
>
> Major points:
> - Now (4.8) ExplicitLAC is to be read with LedgerHandle#readExplicitLAC
> - ExplicitLAC is stored on LedgerStorage
> - Regular LAC is stored inside each entry
> - We have to support Long Poll
> - We have to give access to ExplicitLAC on the new API (but I don't want to
> add a readExplicitLAC on the new API)
> - ExplicitLAC on the write side is only a matter of configuring the
> scheduler, no changes are to be done on application code
>
> Desiderata (from me):
>
> The reader only uses Long-Poll or ReadHandle#readLastAddConfirmed and
> transparently it receives the most accurate information from ExplicitLAC
> and PiggyBacked LAC
>
> In order to achieve this goal we will have to work on many parts, this is
> my list:
> - add current ExplicitLAC on readResponses
> - merge ExplicitLAC and regular LAC on client side
> - support watches for Long-Poll on Bookie side, to be triggered by
> ExplicitLAC
>
>
> Enrico
>
--
Jvrao
---
First they ignore you, then they laugh at you, then they fight you, then
you win. - Mahatma Gandhi