Re: Improve Write performance with Relax durability.

Thanks a lot for taking care and providing this use case. On Wed, Aug 10, 2016 at 3:53 AM, Sijie Guo wrote: > On Wed, Aug 3, 2016 at 12:51 PM, Enrico Olivelli > wrote: > > > Hi Jia, > > I have another similar use case for this feature. > > Let it be a

Re: Improve Write performance with Relax durability.

On Wed, Aug 3, 2016 at 12:51 PM, Enrico Olivelli wrote: > Hi Jia, > I have another similar use case for this feature. > Let it be a ledger a db transaction log. > The client issues a sequence of data manipulation instructions inside the > scope of the transaction, if

Re: Improve Write performance with Relax durability.

Hi Jia, I have another similar use case for this feature. Let it be a ledger a db transaction log. The client issues a sequence of data manipulation instructions inside the scope of the transaction, if everything goes well a commit is finally added to the sequence. From the client perspective it

Re: Improve Write performance with Relax durability.

Thanks a lot for all of your suggestions,I would like to have a try, and will open a jira ticket, and make the proposal, discussion and testing there. On Wed, Jun 8, 2016 at 1:40 PM, Sijie Guo wrote: > I think that's a fair consideration. However I am thinking if we allow >

Re: Improve Write performance with Relax durability.

I think that's a fair consideration. However I am thinking if we allow non-durable ledger, that means 1) application needs to handle the missing entries; 2) the re-replication should handle non-durable ledger by ignoring the non-existing entries if they are missing. But Let's see how Jia is

Re: Improve Write performance with Relax durability.

I was interested in trying something in this area, but never actually got to do it. A few random notes: 1. My suspicion, with no backing data at this point, is that simply skipping the fsync for "non-durable" ledgers might not give a big improvement, just a bit less latency for

Re: Improve Write performance with Relax durability.

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

Re: Improve Write performance with Relax durability.

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

Re: Improve Write performance with Relax durability.

+ distributedlog-user For more input and comments. :) Thanks. On Thu, Jun 2, 2016 at 9:34 AM, Jia Zhai 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)?

Improve Write performance with Relax durability.

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