Knowing there is a correctness issue in LWT, and given users use LWT primarily for correctness, my opinion is we should commit the correctness patch (makes it one of #1, #3 or #4)
I agree we should not cause further delay to 4.0 release (making it one of #3 or #4). Con for #3 would be, applications may have to rework their (and downstreams') configuration(s) to potentially accommodate for the performance regression which may not be ideal for a seamless 4.0 upgrade that we expect users to experience. Now, given this correctness issue has been since the beginning, existing LWT users would notice no new difference potentially w.r.t. correctness since they may have already worked around this bug (if they noticed), so +1 to option #4. On Wed, Nov 11, 2020 at 1:49 PM Benedict Elliott Smith <bened...@apache.org> wrote: > In my opinion, a similar calculus should be applied to 3.0 and 3.11. This > is a(n arguably quite serious) bug, so whatever is not overly onerous to > backport should be considered while they are supported. The work under > discussion has two components: a replacement to the core consensus > algorithm, and mechanisms to ensure safety across range movements. The > latter might be more invasive for 3.x, but the former should be quite easy > to backport and as such probably quite well justified. > > > can it also pluggable (either opt-in or opt-out)? > > I think pluggable means something different to opt-in/opt-out, at least to > me. I'm all for more pluggability, and also for more optionality, but the > decision is very sensitive to context. We need to be able to select between > our options, which for consensus practically means supporting live > migration - which is exceptionally challenging in any general sense (and > perhaps inherently non-pluggable). > > As to future development for consensus, I personally hope the work we are > discussing here will be a strong platform for it, but obviously that's for > the community to decide later on. I think the work to take it forwards to > something epaxos-like will not be that herculean, with some incremental > milestones en route. But that's a totally different discussion for the > future, and either a CEP or a small intercollegiate working group. > > > On 11/11/2020, 18:48, "Michael Semb Wever" <m...@apache.org> wrote: > > > > Regarding CASSANDRA-12126 and 4.0 we are facing several options and > > Benedict, Sylvain and I wanted to get the community feedback on them. > > > > We can: > > > > 1. Try to use Benedict proposal for 4.0 if the community has the > > appetite for it. The main issue there is some potential extra > delay for 4.0 > > 2. Do nothing for 4.0. Meaning do not commit the current patch. > We have > > lived a long time with that issue and we can probably wait a bit > more for a > > proper solution. > > 3. Commit the patch as such, fixing the correctness but > introducing > > potentially some performance issue until we release a better > solution. > > 4. Changing the patch to default to the current behavior but > allowing > > people to enable the new one if the correctness is a problem for > them. > > > > > If these options are for 4.0, is it then (4) that it is getting > applied to 3.0 and 3.11 ? > > If that is the case then I would vote on also applying (4) to 4.0, > given we are now in front of beta4. Please let's not further delay 4.0. > > Post 4.0, if (1) is as described "a parallel implementation of the > same underlying Paxos algorithm" can it also pluggable (either opt-in or > opt-out)? And would/could EPaxos become pluggable too in a similar manner > (if it eventuates)? I'm in favour on providing more pluggable interfaces > into C*, along with the code quality improvements that's going to have to > be accompanied with. > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > For additional commands, e-mail: dev-h...@cassandra.apache.org > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > For additional commands, e-mail: dev-h...@cassandra.apache.org > >
