JGroups - A Toolkit for Reliable Multicast Communication

Channels are deliberately simple so that all possible can use them. However, JGroups also provides high-level abstractions, so called building blocks. They can be put between the application and the channel. The application would then use the building blocks instead of channels. An example is RpcDispatcher which allows applications to make remote group method calls:

public class RpcDispatcherTest {
    Channel       channel;
    RpcDispatcher disp;
    RspList       rsp_list;
    String        props="/home/bela/udp.xml"

    public int print(int number) {
        System.out.println("print(" + number + ")");
        return number * 2;
    }

    public void start() throws Exception {
        channel=new JChannel(props);

        disp=new RpcDispatcher(channel, null, null, this);

        channel.connect("RpcDispatcherTestGroup");

        for(int i=0; i < 100; i++) {

           Util.sleep(1000);

           rsp_list=disp.callRemoteMethods(null, "print", new Integer(i),
                                                  GroupRequest.GET_ALL,
                                                  0);

           System.out.println("Responses: " + rsp_list);
        }

        channel.close();
    }
}

As before, the example creates a channel specifying the properties. It also defines a method print() which will be called by the RpcDispatcher later on. Then an instance of RpcDispatcher is created on top of the channel and the channel connected (this joins the new member to the group). Now, messages can be sent and received. But instead of sending/receiving messages using the channel, the application invokes remote method call using RpcDispatcher's callRemoteMethods().

The first argument 'null' means send to all group members, "print" is the name of the method to be invoked, 'new Integer(i)' is the argument to the print() method, GET_ALL means wait until the responses from all group members have been received and '0' specifies the timeout (in this case, it means wait forever). RpcDispatcher sends a multicast message (containing the method call) to all members (e.g. 4 members, including itself) and waits for 4 replies. If one or more of the members crash in the meantime, the call nevertheless returns and has those replies marked as 'suspected' in the response list. The response list contains an entry for each expected reply, which has the address of the replier, the value (if any, in our case it is an integer), and a flag (received, not received (in case of timeouts) or suspected). If this member is the only group member, then the method call will call its own print() method.

The current set of protocols shipped with JGroups provide Virtual Synchrony properties: messages are sent/received in views. Each member has a view which is a set of members that constitute the current membership. When the membership changes, a new view will be installed by all members. Views are installed in the same order at all members. The set of messages between 2 consecutive views will be the same at all receivers. Messages sent in view V1 will be received by all non-faulty members in view V1.

Through its flexible protocol stack architecture, JGroups can be adapted to any environment. This can be done by replacing, removing or modifying existing protocols, or by adding new protocols. JGroups is an ideal testbed for development and experimentation of new reliable multicast protocols written in Java. As JGroups is an OpenSource project, new protocols are always welcome and will be integrated.