It will use the first contact point to connect to the database and once connected, it will read that peers table, which is empty. Contact points are really just that - contact points. I think it does not mean that all of them will be used in some round-robin fashion or what. They are there just to read that peer's table and use these nodes, not contact points.
I think same would be seen if you specify two contact points where the first one is a non-existing ip address and the second one is proxy. It should connect to that proxy again which reads peers table as empty. I was involved in some investigation around this functionality and I hit the same problem, basically. My idea was to put these proxies to peers table but that complicates things quite fast as they are not proper members of the ring, by definition, as they do not hold data etc .... I think this would need to be fixed in the driver - to included all contact points even they are not found in peers. But, if they are not part of the ring, they can never "leave" the ring. I wonder if they are visible in gossip etc ... I do not remember. Hence, how would you know that your proxy went down? ________________________________________ From: Jeff Jirsa <jji...@gmail.com> Sent: Thursday, October 12, 2023 14:20 To: user@cassandra.apache.org Subject: Re: java driver with cassandra proxies (option: -Dcassandra.join_ring=false) NetApp Security WARNING: This is an external email. Do not click links or open attachments unless you recognize the sender and know the content is safe. Just to be clear: - How many of the proxy nodes are you providing as contact points? One of them or all of them? It sounds like you're saying you're passing all of them, and only one is connecting, and the driver is declining to connect to the rest because they're not in system.peers. I'm not surprised that the proxies aren't in system.peers, but I'd have also expected that if you pass all proxies in contact points, it'd connect to all of them, so I think you're appropriately surprised here. On Thu, Oct 12, 2023 at 5:09 AM Regis Le Bretonnic <r.lebreton...@meetic-corp.com<mailto:r.lebreton...@meetic-corp.com>> wrote: We have tested Stargate and were very disappointed... Originally our architecture was PHP microservices (with FPM) + cassandra proxies. But we were blocked because PHP driver is no more supported. We made tests to keep PHP + stargate but there were many issues, the main one (but not the only one) being stargate does not support "ALLOW FILTERING" clause. I don't want to re-open this debate I already had with Stargate maintainers... We finally decided to move from PHP to java but we'd like to keep cassandra proxies that are very usefull. Regards Le jeu. 12 oct. 2023 à 12:05, Erick Ramirez <erickramire...@apache.org<mailto:erickramire...@apache.org>> a écrit : Those nodes are not in the peers table(s) because you told them NOT to join the ring with `join_ring=false` so it is working by design. I'm not really sure what you're trying to achieve but if you want to separate the coordinator functions from the storage then what you probably want is to deploy Stargate nodes<https://stargate.io/>. Stargate is a data API gateway that sits between the app instances and the Cassandra database. It decouples client request coordination from the storage aspects of C*. It also allows you to perform CRUD operations against C* using APIs -- REST, JSON, gRPC, GraphQL. See the docs on Using the Stargate CQL API<https://stargate.io/docs/latest/develop/dev-with-cql.html> for details on how to set up Stargate nodes as coordinators for your C* database. If you want to see it in action, you can try it free on Astra DB<https://astra.datastax.com/> (Cassandra-as-a-service). Cheers!
