DiscoveryCustomMessage messages are handled by discovery protocol which provides some guarantees around them.
When some node sends
DiscoveryCustomMessage with
GridDiscoveryManager.sendCustomEvent(DiscoveryCustomMessage)
call, message firstly goes to current coordinator, is verified there and after that gets sent to the cluster.
Only after verification it is delivered to listeners on all nodes starting from coordinator.
To register a listener
GridDiscoveryManager.setCustomEventListener(Class, CustomEventListener) method is used.
Discovery protocol guarantees include:
-
All discovery messages are observed by all nodes in exactly the same order,
it is guaranteed by handling them in single-threaded mode.
-
New server node joining process in default implementation involves two passes of different messages across the cluster:
TcpDiscoveryNodeAddedMessage and
TcpDiscoveryNodeAddFinishedMessage messages.
It is guaranteed that all discovery messages observed by coordinator in between these two messages
are reordered and guaranteed to be delivered to newly joined node.
Yet there are some features and limitations one should be aware of when using custom discovery messaging mechanism:
-
Guarantee #2 doesn't encompass DiscoveryCustomMessages created automatically on
ackMessage() method call.
If there were messages of this type in between TcpDiscoveryNodeAddedMessage and
TcpDiscoveryNodeAddFinishedMessage messages, they won't be delivered to new joiner node.
-
There is no guarantee for a given DiscoveryCustomMessage to be delivered only once.
It is possible that because of node failure antecedent node will resend messages
it thinks were not sent by failed node.
Duplicate messages are not filtered out on receiver side.
-
DiscoveryCustomMessages are delivered to client nodes in asynchronous fashion
as clients don't participate in the cluster ring.
-
Any blocking operations like obtaining locks or doing I/O must be avoided in message handlers
as they may lead to deadlocks and cluster failures.