Re: [VOTE] Release Apache Cassandra 4.0.0 (take2)

Thanks for the heads up Jon. Please ping the list once you have filed the jira. Dinesh > On Jul 16, 2021, at 5:28 PM, Jon Meredith wrote: > > -1 nb. > > I'll open a JIRA with details later tonight or first thing tomorrow. > > I've confirmed that the serialization and deserialization of FWD_

Re: [VOTE] Release Apache Cassandra 4.0.0 (take2)

-1 nb. I'll open a JIRA with details later tonight or first thing tomorrow. I've confirmed that the serialization and deserialization of FWD_FRM on 4.0 nodes when communicating with pre-4.0 nodes is incorrect and includes an incorrect single-byte address length. Additionally the logic for whether

Re: [DISCUSS] CEP-9: Make SSLContext creation pluggable

Hi all Thank you for the vote on this. Since the CEP is Accepted now, do we discuss PR/code details on the JIRA/Github right? Thanks Maulin On Wed, Jul 14, 2021 at 5:28 PM Maulin Vasavada wrote: > Thanks Berenguer. Mainly I did detailed PR since I was not familiar with > Cassandra codebase and

Re: [VOTE] Release Apache Cassandra 4.0.0 (take2)

I'd like to request an extension to the vote. There's a possible issue with 4.0 instances serializing FWD_FRM message parameters to pre-4.0 nodes that I'm investigating and need a little more time. On Thu, Jul 15, 2021 at 9:45 AM Sam Tunnicliffe wrote: > > +1 > > > On 13 Jul 2021, at 23:13, Mick

Re: [DISCUSS] The Severity of CASSANDRA-16807

Agreed. In any case, a patch is now available. On Fri, Jul 16, 2021 at 3:32 PM Brandon Williams wrote: > I discussed this with Caleb on slack, and these queries fail in both > 3.x and 4.0. The difference is that in 4.0 they will receive a

Re: [DISCUSS] The Severity of CASSANDRA-16807

I discussed this with Caleb on slack, and these queries fail in both 3.x and 4.0. The difference is that in 4.0 they will receive an internal server error from the assertion, whereas on 3.x they will just receive an incorrect response that they will believe to be correct. Given that this is incor

Re: [VOTE] CIP-9: Make SSLContext creation pluggable

Yay! Thanks Benjamin and everybody who participated. Feeling fully energized to finish the work! On Fri, Jul 16, 2021 at 9:59 AM Benjamin Lerer wrote: > Vote passes with five binding +1, three non binding +1 and no vetos. > > Le mer. 14 juil. 2021 à 16:02, Joshua McKenzie a > écrit : > > > +1 >

[DISCUSS] The Severity of CASSANDRA-16807

tl;dr At best CASSANDRA-16807 means some queries that shouldn't fail do fail, and at worst, this is a potentially dangerous consistency problem. https://issues.apache.org/jira/browse/CASSANDRA-16807 I'm working on a solution either way, but I want to see if there are any opinions out there on whe

Re: [VOTE] CIP-9: Make SSLContext creation pluggable

Vote passes with five binding +1, three non binding +1 and no vetos. Le mer. 14 juil. 2021 à 16:02, Joshua McKenzie a écrit : > +1 > > On Wed, Jul 14, 2021 at 7:03 AM Paulo Motta > wrote: > > > +1 > > > > Em qua., 14 de jul. de 2021 às 02:29, Sumanth Pasupuleti < > > sumanth.pasupuleti...@gmail

Re: [DISCUSS] Virtual Tables and the future of NodeTool/JMX

I would say just go with it. JMX isn’t quite deprecated yet, and if we ever even end up doing that, it’s not going to be any time soon. > On 16 Jul 2021, at 13:32, Stefan Miklosovic > wrote: > > Thanks Benjamin for the understanding, but in the end, let's put aside > the frustration here, I th

Re: [DISCUSS] Virtual Tables and the future of NodeTool/JMX

Thanks Benjamin for the understanding, but in the end, let's put aside the frustration here, I think I can just kind of detach from that. However, in this particular case, I really think we should just finish this and merge it and move on. By not doing so and waiting for the CEP around this, we ar

Re: [DISCUSS] Virtual Tables and the future of NodeTool/JMX

That's a good point. It seems to be able to fully deprecate JMX we will need the following: a) Allow VirtualTables to be settable - to support changing parameters (ie. nodetool setcompactionthroughput 32). b) Support CALL/EXECUTE/INVOKE CQL statements for things like flush and compact etc. When la

Re: [DISCUSS] Virtual Tables and the future of NodeTool/JMX

> > 1) Are people OK with drawing a line after current in-progress patches are > finished and formally disallowing new features from being added to the JMX > interface, but only to VT? If not, what are the concerns and how can we > address them. Virtual Tables are not really suitable for all node

Re: [DISCUSS] Virtual Tables and the future of NodeTool/JMX

> It seems only fair to me to let these patches go in and simply thank the contributors for their efforts and work. We can open some followup tickets for providing those functionalities through Virtual Tables (we are only talking about 2 patches). If nobody else takes them, I will. +1 Sounds like

Re: [DISCUSS] Virtual Tables and the future of NodeTool/JMX

Thanks a lot for all the feedback, I really appreciate the discussion and Paulo's proposals. Regarding the ongoing patches: Based on the discussion, it clearly appears that nodetool will still be there for some time (and will be there in the next major release). As such, it seems to me that the c

Re: [DISCUSS] Virtual Tables and the future of NodeTool/JMX

> > > Until CEP exists and is approved, work on patches in flight seems > reasonable and valid. > > This is right, but when there is an active discussion about changing the > status quo it's polite to wait for the outcome of the discussion - or help > it make progress - before making potentially co