+1 to correctness, and I like the yaml idea > On Nov 23, 2020, at 4:20 AM, Paulo Motta <pauloricard...@gmail.com> wrote: > > +1 to defaulting for correctness. > > In addition to that, how about making it a mandatory cassandra.yaml > property defaulting to correctness? This would make upgrades with an old > cassandra.yaml fail unless an option is explicitly specified, making > operators aware of the issue and forcing them to make a choice. > >> Em seg., 23 de nov. de 2020 às 07:30, Benjamin Lerer < >> benjamin.le...@datastax.com> escreveu: >> >> Thank you very much to everybody that provided feedback. It helped a lot to >> limit our options. >> >> Unfortunately, it seems that some poor soul (me, really!!!) will have to >> make the final call between #3 and #4. >> >> If I reformulate the question to: Do we default to *correctness *or to >> *performance*? >> >> I would choose to default to *correctness*. >> >> Of course the situation is more complex than that but it seems that >> somebody has to make a call and live with it. It seems to me that being >> blamed for choosing correctness is easier to live with ;-) >> >> Benjamin >> >> PS: I tried to push the choice on Sylvain but he dodged the bullet. >> >> On Sat, Nov 21, 2020 at 12:30 AM Benedict Elliott Smith < >> bened...@apache.org> >> wrote: >> >>> I think I meant #4 __♂️ >>> >>> On 20/11/2020, 21:11, "Blake Eggleston" <beggles...@apple.com.INVALID> >>> wrote: >>> >>> I’d also prefer #3 over #4 >>> >>>> On Nov 20, 2020, at 10:03 AM, Benedict Elliott Smith < >>> bened...@apache.org> wrote: >>>> >>>> Well, I expressed a preference for #3 over #4, particularly for >> the >>> 3.x series. However at this point, I think the lack of a clear project >>> decision means we can punt it back to you and Sylvain to make the final >>> call. >>>> >>>> On 20/11/2020, 16:23, "Benjamin Lerer" < >> benjamin.le...@datastax.com> >>> wrote: >>>> >>>> I will try to summarize the discussion to clarify the outcome. >>>> >>>> Mick is in favor of #4 >>>> Summanth is in favor of #4 >>>> Sylvain answer was not clear for me. I understood it like I >>> prefer #3 to #4 >>>> and I am also fine with #1 >>>> Jeff is in favor of #3 and will understand #4 >>>> David is in favor #3 (fix bug and add flag to roll back to old >>> behavior) in >>>> 4.0 and #4 in 3.0 and 3.11 >>>> >>>> Do not hesitate to correct me if I misunderstood your answer. >>>> >>>> Based on these answers it seems clear that most people prefer to >>> go for #3 >>>> or #4. >>>> >>>> The choice between #3 (fix correctness opt-in to current >>> behavior) and #4 >>>> (current behavior opt-in to correctness) is a bit less clear >>> specially if >>>> we consider the 3.X branches or 4.0. >>>> >>>> Does anybody as some idea on how to choose between those 2 >>> choices or some >>>> extra opinions on #3 versus #4? >>>> >>>> >>>> >>>> >>>> >>>> >>>>> On Wed, Nov 18, 2020 at 9:45 PM David Capwell < >>> dcapw...@gmail.com> wrote: >>>>> >>>>> I feel that #4 (fix bug and add flag to roll back to old behavior) >>> is best. >>>>> >>>>> About the alternative implementation, I am fine adding it to 3.x >>> and 4.0, >>>>> but should treat it as a different path disabled by default that >>> you can >>>>> opt-into, with a plan to opt-in by default "eventually". >>>>> >>>>> On Wed, Nov 18, 2020 at 11:10 AM Benedict Elliott Smith < >>>>> bened...@apache.org> >>>>> wrote: >>>>> >>>>>> Perhaps there might be broader appetite to weigh in on which >> major >>>>>> releases we might target for work that fixes the correctness bug >>> without >>>>>> serious performance regression? >>>>>> >>>>>> i.e., if we were to fix the correctness bug now, introducing a >>> serious >>>>>> performance regression (either opt-in or opt-out), but were to >>> land work >>>>>> without this problem for 5.0, would there be appetite to backport >>> this >>>>> work >>>>>> to any of 4.0, 3.11 or 3.0? >>>>>> >>>>>> >>>>>> On 18/11/2020, 18:31, "Jeff Jirsa" <jji...@gmail.com> wrote: >>>>>> >>>>>> This is complicated and relatively few people on earth >>> understand it, >>>>>> so >>>>>> having little feedback is mostly expected, unfortunately. >>>>>> >>>>>> My normal emotional response is "correctness is required, >>> opt-in to >>>>>> performance improvements that sacrifice strict correctness", >>> but I'm >>>>>> also >>>>>> sure this is going to surprise people, and would understand / >>> accept >>>>> #4 >>>>>> (default to current, opt-in to correct). >>>>>> >>>>>> >>>>>> On Wed, Nov 18, 2020 at 4:54 AM Benedict Elliott Smith < >>>>>> bened...@apache.org> >>>>>> wrote: >>>>>> >>>>>>> It doesn't seem like there's much enthusiasm for any of the >>> options >>>>>>> available here... >>>>>>> >>>>>>> On 12/11/2020, 14:37, "Benedict Elliott Smith" < >>>>> bened...@apache.org >>>>>>> >>>>>>> wrote: >>>>>>> >>>>>>>> Is the new implementation a separate, distinctly modularized >>>>>> new >>>>>>> body of work >>>>>>> >>>>>>> It’s primarily a distinct, modularised and new body of work, >>>>>> however >>>>>>> there is some shared code that has been modified - namely >>>>>> PaxosState, in >>>>>>> which legacy code is maintained but modified for compatibility, >>> and >>>>>> the >>>>>>> system.paxos table (which receives a new column, and slightly >>>>>> modified >>>>>>> serialization code). It is conceptually an optimised version of >>>>> the >>>>>>> existing algorithm. >>>>>>> >>>>>>> If there's a chance of being of value to 4.0, I can try to >> put >>>>>> up a >>>>>>> patch next week alongside a high level description of the >> changes. >>>>>>> >>>>>>>> But a performance regression is a regression, I'm not >>>>>> shrugging it >>>>>>> off. >>>>>>> >>>>>>> I don't want to give the impression I'm shrugging off the >>>>>> correctness >>>>>>> issue either. It's a serious issue to fix, but since all >>> successful >>>>>> updates >>>>>>> to the database are linearizable, I think it's likely that many >>>>>>> applications behave correctly with the present semantics, or at >>>>> least >>>>>>> encounter only transient errors. No doubt many also do not, but >> I >>>>>> have no >>>>>>> idea of the ratio. >>>>>>> >>>>>>> The regression isn't itself a simple issue either - depending >>>>> on >>>>>> the >>>>>>> topology and message latencies it is not difficult to produce >>>>>> inescapable >>>>>>> contention, i.e. guaranteed timeouts - that might persist as >> long >>>>> as >>>>>>> clients continue to retry. It could be quite a serious >> degradation >>>>> of >>>>>>> service to impose on our users. >>>>>>> >>>>>>> I don't pretend to know the correct way to make a decision >>>>>> balancing >>>>>>> these considerations, but I am perhaps more concerned about >>>>> imposing >>>>>>> service outages than I am temporarily maintaining semantics our >>>>>> users have >>>>>>> apparently accepted for years - though I absolutely share your >>>>>>> embarrassment there. >>>>>>> >>>>>>> >>>>>>> On 12/11/2020, 12:41, "Joshua McKenzie" < >> jmcken...@apache.org >>>>>> >>>>>> wrote: >>>>>>> >>>>>>> Is the new implementation a separate, distinctly >>>>> modularized >>>>>> new >>>>>>> body of >>>>>>> work or does it make substantial changes to existing >>>>>>> implementation and >>>>>>> subsume it? >>>>>>> >>>>>>> On Thu, Nov 12, 2020 at 3:56 AM Sylvain Lebresne < >>>>>>> lebre...@gmail.com> wrote: >>>>>>> >>>>>>>> Regarding option #4, I'll remark that experience tends to >>>>>>> suggest users >>>>>>>> don't consistently read the `NEWS.txt` file on upgrade, >>>>> so >>>>>>> option #4 will >>>>>>>> likely essentially mean "LWT has a correctness issue, but >>>>>> once >>>>>>> it broke >>>>>>>> your data enough that you'll notice, you'll be able to >>>>> dig >>>>>> the >>>>>>> proper flag >>>>>>>> to fix it for next time". I guess it's better than >>>>>> nothing, of >>>>>>> course, but >>>>>>>> I'll admit that defaulting to "opt-in correctness", >>>>>> especially >>>>>>> for a >>>>>>>> feature (LWT) that exists uniquely to provide additional >>>>>>> guarantees, is >>>>>>>> something I have a hard rallying behind. >>>>>>>> >>>>>>>> But a performance regression is a regression, I'm not >>>>>> shrugging >>>>>>> it off. >>>>>>>> Still, I feel we shouldn't leave LWT with a fairly >>>>> serious >>>>>> known >>>>>>>> correctness bug and I frankly feel bad for "the project" >>>>>> that >>>>>>> this has been >>>>>>>> known for so long without action, so I'm a bit biased in >>>>>> wanting >>>>>>> to get it >>>>>>>> fixed asap. >>>>>>>> >>>>>>>> But maybe I'm overstating the urgency here, and maybe >>>>>> option #1 >>>>>>> is a better >>>>>>>> way forward. >>>>>>>> >>>>>>>> -- >>>>>>>> Sylvain >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> >>> --------------------------------------------------------------------- >>>>>>> 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 >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>> --------------------------------------------------------------------- >>>>>> 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 >>>> >>> >>> --------------------------------------------------------------------- >>> 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 >>> >>> >>
--------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org
