Package org.jgroups.protocols

Class SHUFFLE

  • All Implemented Interfaces:
    Lifecycle
    public class SHUFFLE
extends Protocol
    Reorders messages by buffering them and shuffling the result after TIMEOUT ms.
    Author:
    Bela Ban

    • Field Detail

      • up_msgs

        protected java.util.List<Message> up_msgs

      • down_msgs

        protected java.util.List<Message> down_msgs

      • up_lock

        protected final java.util.concurrent.locks.Lock up_lock

      • down_lock

        protected final java.util.concurrent.locks.Lock down_lock

      • task

        protected java.util.concurrent.Future<?> task

      • up

        protected boolean up

      • down

        protected boolean down

      • max_size

        protected int max_size

      • max_time

        protected long max_time

    • Constructor Detail

      • SHUFFLE

        public SHUFFLE()

    • Method Detail

      • getUpMessages

        public int getUpMessages()

      • getDownMessages

        public int getDownMessages()

      • isUp

        public boolean isUp()

      • setUp

        public SHUFFLE setUp​(boolean up)

      • isDown

        public boolean isDown()

      • setDown

        public SHUFFLE setDown​(boolean down)

      • getMaxSize

        public int getMaxSize()

      • setMaxSize

        public SHUFFLE setMaxSize​(int max_size)

      • getMaxTime

        public long getMaxTime()

      • setMaxTime

        public SHUFFLE setMaxTime​(long max_time)

      • init

        public void init()
          throws java.lang.Exception
        Description copied from class: Protocol
        Called after a protocol has been created and before the protocol is started. Attributes are already set. Other protocols are not yet connected and events cannot yet be sent.
        Specified by:
        init in interface Lifecycle
        Overrides:
        init in class Protocol
        Throws:
        java.lang.Exception - Thrown if protocol cannot be initialized successfully. This will cause the ProtocolStack to fail, so the the channel constructor will throw an exception

      • start

        public void start()
           throws java.lang.Exception
        Description copied from class: Protocol
        This method is called on a JChannel.connect(String); starts work. Protocols are connected ready to receive events. Will be called from bottom to top.
        Specified by:
        start in interface Lifecycle
        Overrides:
        start in class Protocol
        Throws:
        java.lang.Exception - Thrown if protocol cannot be started successfully. This will cause the ProtocolStack to fail, so JChannel.connect(String) will throw an exception

      • down

        public java.lang.Object down​(Message msg)
        Description copied from class: Protocol
        A message is sent down the stack. Protocols may examine the message and do something (e.g. add a header) with it, before passing it down.
        Overrides:
        down in class Protocol

      • up

        public java.lang.Object up​(Message msg)
        Description copied from class: Protocol
        A single message was received. Protocols may examine the message and do something (e.g. add a header) with it before passing it up.
        Overrides:
        up in class Protocol

      • up

        public void up​(MessageBatch batch)
        Description copied from class: Protocol
        Sends up a multiple messages in a MessageBatch. The sender of the batch is always the same, and so is the destination (null == multicast messages). Messages in a batch can be OOB messages, regular messages, or mixed messages, although the transport itself will create initial MessageBatches that contain only either OOB or regular messages.

        The default processing below sends messages up the stack individually, based on a matching criteria (calling Protocol.accept(Message)), and - if true - calls Protocol.up(org.jgroups.Event) for that message and removes the message. If the batch is not empty, it is passed up, or else it is dropped.

        Subclasses should check if there are any messages destined for them (e.g. using MessageBatch.iterator(Predicate)), then possibly remove and process them and finally pass the batch up to the next protocol. Protocols can also modify messages in place, e.g. ENCRYPT could decrypt all encrypted messages in the batch, not remove them, and pass the batch up when done.

        Overrides:
        up in class Protocol
        Parameters:
        batch - The message batch

      • flush

        public void flush​(boolean stop_shuffling)

      • shuffle

        protected static void shuffle​(MessageBatch batch)

      • startTask

        protected void startTask()

      • stopTask

        public void stopTask()

      • add

        protected SHUFFLE add​(java.util.List<Message> queue,
                      Message msg,
                      java.util.concurrent.locks.Lock lock,
                      java.util.function.Consumer<Message> send_function)

      • add

        protected SHUFFLE add​(java.util.List<Message> queue,
                      MessageBatch batch,
                      java.util.concurrent.locks.Lock lock,
                      java.util.function.Consumer<Message> send_function)

      • reorderAndSend

        protected SHUFFLE reorderAndSend​(java.util.List<Message> list,
                                 java.util.concurrent.locks.Lock lock,
                                 java.util.function.Consumer<Message> send_function)