And event pushed by the server. A client will only receive events for the
type it has REGISTER to. The body of an EVENT message will start by a
string representing the event type. The rest of the message depends on the
event type. The valid event types are:
- "TOPOLOGY_CHANGE": events related to change in the cluster topology.
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.
- "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
type of status change ("UP" or "DOWN") followed by the address of the
concerned node.
- "SCHEMA_CHANGE": events related to schema change. The body of the message
(after the event type) consists of 3 string corresponding respectively
to the type of schema change ("CREATED", "UPDATED" or "DROPPED"),
followed by the name of the affected keyspace and the name of the
affected table within that keyspace. For changes that affect a keyspace
directly, the table name will be empty (i.e. the empty string "").
All EVENT message have a streamId of -1 (Section 2.3).
Please note that "NEW_NODE" and "UP" events are sent based on internal Gossip
communication and as such may be sent a short delay before the binary
protocol server on the newly up node is fully started. Clients are thus
advise to wait a short time before trying to connect to the node (1 seconds
should be enough), otherwise they may experience a connection refusal at
first.
4.2.6. EVENT
And event pushed by the server. A client will only receive events for the type it has REGISTER to. The body of an EVENT message will start by a string representing the event type. The rest of the message depends on the event type. The valid event types are: - "TOPOLOGY_CHANGE": events related to change in the cluster topology. 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. - "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 type of status change ("UP" or "DOWN") followed by the address of the concerned node. - "SCHEMA_CHANGE": events related to schema change. The body of the message (after the event type) consists of 3 string corresponding respectively to the type of schema change ("CREATED", "UPDATED" or "DROPPED"), followed by the name of the affected keyspace and the name of the affected table within that keyspace. For changes that affect a keyspace directly, the table name will be empty (i.e. the empty string "").
All EVENT message have a streamId of -1 (Section 2.3).
Please note that "NEW_NODE" and "UP" events are sent based on internal Gossip communication and as such may be sent a short delay before the binary protocol server on the newly up node is fully started. Clients are thus advise to wait a short time before trying to connect to the node (1 seconds should be enough), otherwise they may experience a connection refusal at first.