[ 
https://issues.apache.org/jira/browse/CASSANDRA-8345?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14220039#comment-14220039
 ] 

Bulat Shakirzyanov commented on CASSANDRA-8345:
-----------------------------------------------

Each driver receives notifications only from a single node, why would it need 
to reconcile, isn't the notification pushed from the node after schema has been 
reconciled?

> Client notifications should carry the entire delta of the information that 
> changed
> ----------------------------------------------------------------------------------
>
>                 Key: CASSANDRA-8345
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-8345
>             Project: Cassandra
>          Issue Type: Improvement
>            Reporter: Michaël Figuière
>              Labels: protocolv4
>
> Currently when the schema changes, a {{SCHEMA_CHANGE}} notification is sent 
> to the client to let it know that a modification happened in a specific table 
> or keyspace. If the client register for these notifications, this is likely 
> that it actually cares to have an up to date version of this information, so 
> the next step is logically for the client to query the {{system}} keyspace to 
> retrieve the latest version of the schema for the particular element that was 
> mentioned in the notification.
> The same thing happen with the {{TOPOLOGY_CHANGE}} notification as the client 
> will follow up with a query to retrieve the details that changed in the 
> {{system.peers}} table.
> It would be interesting to send the entire delta of the information that 
> changed within the notification. I see several advantages with this:
> * This would ensure that the data that are sent to the client are as small as 
> possible as such a delta will always be smaller than the resultset that would 
> eventually be received for a formal query on the {{system}} keyspace.
> * This avoid the Cassandra node to receive plenty of query after it issue a 
> notification but rather to prepare a delta once and send it to everybody.
> * This should improve the overall behaviour when dealing with very large 
> schemas with frequent changes (typically due to a tentative of implementing 
> multitenancy through separate keyspaces), as it has been observed that the 
> the notifications and subsequent queries traffic can become non negligible in 
> this case.
> * This would eventually simplify the driver design by removing the need for 
> an extra asynchronous operation to follow up with, although the benefit of 
> this point will be real only once the previous versions of the protocols are 
> far behind.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to