Re: [EXTERNAL] Re: [Discuss] Generic Purpose Rate Limiter in Cassandra

I see a lot of great ideas being discussed or proposed in the past to cover the most common rate limiter candidate use cases. Do folks think we should file an official CEP and take it there? Jaydeep On Fri, Feb 2, 2024 at 8:30 AM Caleb Rackliffe wrote: > I just remembered the other day that I h

Re: [Discuss] CASSANDRA-16999 introduction of a column in system.peers_v2

Correct. But that initial connection will work and the client will work, it just won’t have connections to multiple nodes. I didn’t say it’s optimal, but this is the best way I can see that doesn’t break things more than they are now, and does give an improvement because you can pick which port

Re: [Discuss] CASSANDRA-16999 introduction of a column in system.peers_v2

> For existing versions what about having a “default ssl” or “default no SSL” > yaml setting which decides what port is advertised? Then someone could still > connect on the other port manually specifying. Then new column can be added > with the new table in trunk. I'm assuming "advertisement

Re: [Discuss] CASSANDRA-16999 introduction of a column in system.peers_v2

We should not introduce a new column in a patch release. From what I have seen many drivers “select * from peers”, yes it’s not a good idea, but we can’t control what all clients do, and an extra column coming back may break the processing of that.For existing versions what about having a “default

Re: [Discuss] CASSANDRA-16999 introduction of a column in system.peers_v2

Honest to god, I do not know, Abe. If I see a feedback where we reach consensus to deprecate dual port support, I will deprecate that. On Wed, Feb 7, 2024 at 12:42 PM Abe Ratnofsky wrote: > CASSANDRA-9590 (Support for both encrypted and unencrypted native > transport connections) was implemented

Re: [Discuss] CASSANDRA-16999 introduction of a column in system.peers_v2

CASSANDRA-9590 (Support for both encrypted and unencrypted native transport connections) was implemented before CASSANDRA-10559 (Support encrypted and plain traffic on the same port), but both been available since 3.0. On 9590, STARTTLS was considered, but rejected due to the changes that would

Re: [Discuss] CASSANDRA-16999 introduction of a column in system.peers_v2

More context behind dual native port support might be found here https://issues.apache.org/jira/browse/CASSANDRA-9590 where it was implemented. On Wed, Feb 7, 2024 at 12:07 PM Abe Ratnofsky wrote: > What is the audience for dual-native-port operation? My understanding is > that most users can us

Re: [Discuss] CASSANDRA-16999 introduction of a column in system.peers_v2

What is the audience for dual-native-port operation? My understanding is that most users can use a single port for optional SSL, ever since CASSANDRA-10559 . Using a single port for both encrypted and unencrypted traffic also makes clients m

[Discuss] CASSANDRA-16999 introduction of a column in system.peers_v2

Hi list, there is CASSANDRA-16999 which introduces native_port_ssl into system.peers_v2 table. The reasoning behind that is that without this, Cassandra Java Driver (both 3.x and 4.x branches) are not able to discover nodes when dual no-ssl / ssl communication is enabled. To be more specific, if