I think if a ledger is configured to be non-durable, it is kind of application's responsibility to tolerant the data loss. So I don't think it actually will have to change any in the bookkeeper client side.
- Sijie On Thu, Jun 2, 2016 at 7:29 AM, Venkateswara Rao Jujjuri <[email protected]> wrote: > I agree that we must make this ledger property not perEntry write property. > > But, biggest doubt in my mind is - this changes something fundamental. LAC. > Are we allowing sparse ledger? in failure scenario? Handling read side may > become more complex. > > On Thu, Jun 2, 2016 at 12:19 AM, Sijie Guo <[email protected]> wrote: > >> This seems interesting to me. However, it might be safe to start with a >> flag configured per ledger, rather than per entry. Also, it would be good >> to hear the opinions from other people. JV, Matteo? (If I remembered >> correctly, Matteo mentioned that Yahoo might be working on similar thing) >> >> +1 for creating a BOOKKEEPER jira to track this. >> >> - Sijie >> >> On Wed, Jun 1, 2016 at 6:37 PM, Jia Zhai <[email protected]> wrote: >> >> > + distributedlog-user >> > For more input and comments. :) >> > >> > Thanks. >> > >> > On Thu, Jun 2, 2016 at 9:34 AM, Jia Zhai <[email protected]> wrote: >> > >> >> Hello all, >> >> >> >> I am wondering do you guys have any plans on supporting relax >> durability. >> >> Is it a good feature to have in bookkeeper (also for DistributedLog)? >> >> >> >> I am thinking adding a new flag to bookkeeper#addEntry(..., Boolean >> >> sync). So the application can control whether to sync or not for >> individual >> >> entries. >> >> >> >> - On the write protocol, adding a flag to indicate whether this write >> >> should sync to disk or not. >> >> - On the bookie side, if the addEntry request is sync, going through >> >> original pipeline. If the addEntry disables sync, complete the add >> >> callbacks after writing to the journal file and before flushing >> journal. >> >> - Those add entries (disabled syncs) will be flushed to disks with >> >> subsequent sync add entries. >> >> >> >> To my use cases on DistributedLog, this feature can be used for >> >> supporting streams that don't have strong durability requirements. >> >> >> >> What do you guys think? Shall I create a jira to implement this? >> >> >> >> Thanks a lot >> >> -Jia >> >> >> > >> > -- >> > You received this message because you are subscribed to the Google >> Groups >> > "distributedlog-user" group. >> > To unsubscribe from this group and stop receiving emails from it, send >> an >> > email to [email protected]. >> > To post to this group, send email to >> [email protected]. >> > To view this discussion on the web visit >> > >> https://groups.google.com/d/msgid/distributedlog-user/CALsc%2BXpJj3YT47bognhmEhHmahJkCgJUUY6Un4HVczfK_1MxPQ%40mail.gmail.com >> > < >> https://groups.google.com/d/msgid/distributedlog-user/CALsc%2BXpJj3YT47bognhmEhHmahJkCgJUUY6Un4HVczfK_1MxPQ%40mail.gmail.com?utm_medium=email&utm_source=footer >> > >> > . >> > For more options, visit https://groups.google.com/d/optout. >> > >> > > > > -- > Jvrao > --- > First they ignore you, then they laugh at you, then they fight you, then > you win. - Mahatma Gandhi > > > -- > You received this message because you are subscribed to the Google Groups > "distributedlog-user" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To post to this group, send email to [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/distributedlog-user/CAKKTCLXLqqW6q3V%2Br%3Dt%3DdOhq-gue_fWNpAgaFrMXw%3DaCHUFomQ%40mail.gmail.com > <https://groups.google.com/d/msgid/distributedlog-user/CAKKTCLXLqqW6q3V%2Br%3Dt%3DdOhq-gue_fWNpAgaFrMXw%3DaCHUFomQ%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > > For more options, visit https://groups.google.com/d/optout. >
