On Mon, Jul 6, 2015 at 1:13 AM, Atri Sharma <atri.j...@gmail.com> wrote:
> Sounds good. > > I also propose controlling this behaviour through user settable option > (since this might potentially have some performance implications). So if > the user is doing ad hoc analytics, he/she might not care much about bit of > data loss and might prefer the performance gain instead. > I agree. Atri, can you please create a ticket describing this behavior? We can move this discussion there. > > On Mon, Jul 6, 2015 at 1:40 PM, Dmitriy Setrakyan <dsetrak...@apache.org> > wrote: > > > On Mon, Jul 6, 2015 at 1:00 AM, Atri Sharma <atri.j...@gmail.com> wrote: > > > > > Can some sort of persistent Write Ahead Logging help here? > > > > > > > I think so. Perhaps we can have the same type of queue on the backup > nodes > > which will only get flushed in case of primary node failure? > > > > > > > > > > On Mon, Jul 6, 2015 at 11:32 AM, Dmitriy Setrakyan < > > dsetrak...@apache.org> > > > wrote: > > > > > > > On Sun, Jul 5, 2015 at 10:58 PM, Vladimir Ozerov < > voze...@gridgain.com > > > > > > > wrote: > > > > > > > > > Igniters, > > > > > > > > > > Can someone explain me how write-behind store should behave in case > > of > > > > node > > > > > stop when some changes has not been flushed to the underlying store > > > yet? > > > > > Are we guarantee that all pending changes will be flushed to the > > > > underlying > > > > > store? > > > > > > > > > > > > > > I think we should make the best effort to persist the un-flushed > > updates > > > in > > > > case of graceful exit. Of course, not guarantees can be provided, and > > if > > > a > > > > server stop abruptly, then some updates might be lost. > > > > > > > > > > > > > Vladimir. > > > > > > > > > > > > > > > > > > > > > -- > > > Regards, > > > > > > Atri > > > *l'apprenant* > > > > > > > > > -- > Regards, > > Atri > *l'apprenant* >
