worryg0d commented on PR #1929: URL: https://github.com/apache/cassandra-gocql-driver/pull/1929#issuecomment-3889998662
Thanks @joao-r-reis, for your feedback and for explaining the architecture. So, to summarize: 1. 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. 2. 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. 3. 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. Thanks for explaining this. My overall understanding was opposite; I treated C* as a source of truth and thought about this as a listener for events returned by C*, not driver state changes. 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. I'm going to dive into implementations of other drivers, such as the Java one, and possibly C#, to expand my understanding of their internals. Please correct me if I missed something -- 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]
