joao-r-reis commented on PR #1929: URL: https://github.com/apache/cassandra-gocql-driver/pull/1929#issuecomment-3890517222
> C* drivers follow the driver trust model when providing support for custom C* event listeners. The driver decides whether it should call a listener callback or not by following its own reasoning mechanisms. E.g., if the driver successfully establishes a connection to a new C* node, it should call TopologyChangeListener.OnNewNode(). Therefore, each change to the driver ring state triggers a call to the listener callback. Yes but in that scenario establishing a connection to a new C* node that had 0 connections previously would transition the node state from DOWN to UP, it wouldnt be an ADDED event. the ADDED event would have been sent previously when the node was added to the ring even before the connection attempt. I didn't check if the order looks like this exactly in gocql but the point still stands that it's two different things. In the java driver DOWN/UP is only determined by whether the driver has opened connections (pool or control). For the purpose of this PR we shouldn't try and change the internal host state handling of gocql to align more with the java driver's handling (unless there's some really nasty case where it just doesn't make any sense but I doubt that's the case) so we should just rely on whatever gocql has at the moment to call the user's listeners. Same for topology events. > The status events never result in the client listener notification. Instead, only the driver decides whether the node is UP or DOWN. I assume it relies on the host heartbeat mechanisms. I didn't dive into implementations of other drivers; I assume they trigger host heartbeats when a STATUS event is received to decide whether the node is actually alive or not. From what I understood the java driver's heartbeats control whether the connection is closed (and reconnections triggered) or not. What determines whether a node is DOWN or UP is whether there are open and initialized connections for that node or not. I believe gocql handles this a bit differently and at some point we should try to change it to behave a bit more like the java driver behavior which makes more sense to me personally. Right now I think the C* UP event is handled similarly to the java driver but the C* DOWN event actually makes gocql close all the connections to that host immediately which isn't great. At the very least the driver should attempt to close them gracefully but it doesn't so I don't think the current DOWN event handling brings any benefits at all even if some cloud service like AWS Keyspaces or Astra wants to send DOWN events to make gocql close connections before shutting down or something. > Schema events returned by C* result in the refreshing of the internal driver metadata, and only if the fetched metadata is different from the one cached by the driver (so the previous one), we call the corresponding listeners. So, some abstract metadata manager is responsible for calling SCHEMA listeners. > And the main point, listeners are actually listeners for changes in the driver's internal state - metadata or ring. Yes that's correct. > Thinking about this, it actually makes sense, as if the driver is connected to 3 nodes, each could send a SCHEMA event to a single client, which we don't care about, as the driver is already aware of changes. Technically it shouldn't happen because we subscribe these events only on the control connection but one of the benefits of this is that we can guarantee to the user that they will get events for every schema change even if the control connection is disconnected during such change. Example: 1 - Control connection initializes 2 - Control connection fetches schema metadata 3 - Connection is closed and has to be reconnected 4 - Schema change happens while the control connection is disconnected 5 - Control connection reconnects, fetches metadata again 6 - Compute diff compared to old metadata and generate user events accordingly (we never received a C* event for the schema change that happened in step 4) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
