From 72c6ed2883a24486f6785b53cf73fdc8e78e2765 Mon Sep 17 00:00:00 2001 From: Michael Penick Date: Tue, 3 Mar 2015 12:47:41 -0600 Subject: [PATCH] Add missing MOVED_NODE event to native protocol spec Patch by Michael Penick; reviewed by Tyler Hobbs for CASSANDRA-7816 --- doc/native_protocol_v1.spec | 7 +++++-- doc/native_protocol_v2.spec | 8 ++++++-- 2 files changed, 11 insertions(+), 4 deletions(-) diff --git a/doc/native_protocol_v1.spec b/doc/native_protocol_v1.spec index bc2bb789f4..41146f97da 100644 --- a/doc/native_protocol_v1.spec +++ b/doc/native_protocol_v1.spec @@ -486,8 +486,8 @@ Table of Contents Currently, events are sent when new nodes are added to the cluster, and when nodes are removed. The body of the message (after the event type) consists of a [string] and an [inet], corresponding respectively to the - type of change ("NEW_NODE" or "REMOVED_NODE") followed by the address of - the new/removed node. + type of change ("NEW_NODE", "REMOVED_NODE", or "MOVED_NODE") followed + by the address of the new/removed/moved node. - "STATUS_CHANGE": events related to change of node status. Currently, up/down events are sent. The body of the message (after the event type) consists of a [string] and an [inet], corresponding respectively to the @@ -509,6 +509,9 @@ Table of Contents should be enough), otherwise they may experience a connection refusal at first. + It is possible for the same event to be sent multiple times. Therefore, + a client library should ignore the same event if it has already been notified + of a change. 5. Compression diff --git a/doc/native_protocol_v2.spec b/doc/native_protocol_v2.spec index ef54099d71..584ae2f6f5 100644 --- a/doc/native_protocol_v2.spec +++ b/doc/native_protocol_v2.spec @@ -604,8 +604,8 @@ Table of Contents Currently, events are sent when new nodes are added to the cluster, and when nodes are removed. The body of the message (after the event type) consists of a [string] and an [inet], corresponding respectively to the - type of change ("NEW_NODE" or "REMOVED_NODE") followed by the address of - the new/removed node. + type of change ("NEW_NODE", "REMOVED_NODE", or "MOVED_NODE") followed + by the address of the new/removed/moved node. - "STATUS_CHANGE": events related to change of node status. Currently, up/down events are sent. The body of the message (after the event type) consists of a [string] and an [inet], corresponding respectively to the @@ -627,6 +627,10 @@ Table of Contents should be enough), otherwise they may experience a connection refusal at first. + It is possible for the same event to be sent multiple times. Therefore, + a client library should ignore the same event if it has already been notified + of a change. + 4.2.7. AUTH_CHALLENGE A server authentication challenge (see AUTH_RESPONSE (Section 4.1.2) for more