natas_hw
/
cassandra
mirror of https://github.com/apache/cassandra
0
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Merge branch 'cassandra-2.0' into cassandra-2.1

This commit is contained in:
Tyler Hobbs 2015-03-03 12:50:20 -06:00
parent 2f7077c06c 72c6ed2883
commit 3f6ad3c988
3 changed files with 17 additions and 6 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

7
doc/native_protocol_v1.spec
View File

@ -488,8 +488,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
@ -514,6 +514,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

8
doc/native_protocol_v2.spec
View File

@ -606,8 +606,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
@ -632,6 +632,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

8
doc/native_protocol_v3.spec
View File

@ -660,8 +660,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
@ -691,6 +691,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