public class ReceiverAdapter
An adapter implementing the Receiver interface with no-op implementations. When implementing a
callback, we can simply extend ReceiverAdapter and overwrite receive() in order to not having to
implement all callbacks of the interface.
public void getState(java.io.OutputStream output)
Allows an application to write a state through a provided OutputStream. After the state has
been written the OutputStream doesn't need to be closed as stream closing is automatically
done when a calling thread returns from this callback.
java.lang.Exception - if the streaming fails, any exceptions should be thrown so that the state requester
can re-throw them and let the caller know what happened
public void setState(java.io.InputStream input)
Allows an application to read a state through a provided InputStream. After the state has been
read the InputStream doesn't need to be closed as stream closing is automatically done when a
calling thread returns from this callback.
Called when a change in membership has occurred. No long running actions, sending of messages
or anything that could block should be done in this callback. If some long running action
needs to be performed, it should be done in a separate thread.
Note that on reception of the first view (a new member just joined), the channel will not yet
be in the connected state. This only happens when Channel.connect(String) returns.
Called (usually by the FLUSH protocol), as an indication that the member should stop sending
messages. Any messages sent after returning from this callback might get blocked by the FLUSH
protocol. When the FLUSH protocol is done, and messages can be sent again, the FLUSH protocol
will simply unblock all pending messages. If a callback for unblocking is desired, implement
MembershipListener.unblock(). Note that block() is the equivalent
of reception of a BlockEvent in the pull mode.
Called after the FLUSH protocol has unblocked previously blocked senders, and
messages can be sent again. This callback only needs to be implemented if we require a
notification of that.
Note that during new view installation we provide guarantee that unblock invocation strictly
follows view installation at some node A belonging to that view . However, some other message
M may squeeze in between view and unblock callbacks.
For more details see https://jira.jboss.org/jira/browse/JGRP-986