Technical stream session 5 jgroups
1 / 17

Technical Stream Session 5: JGroups - PowerPoint PPT Presentation

  • Uploaded on

Distributed Systems. Technical Stream Session 5: JGroups. CSC 253 Gordon Blair, François Ta ïani. Overview of the Session. What is JGroups? JGroups’ Architecture The Channel Class The Protocol Stack Infrastructure The Building Blocks Comparison with JMS. What is JGroups?.

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
Download Presentation

PowerPoint Slideshow about 'Technical Stream Session 5: JGroups' - omana

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
Technical stream session 5 jgroups

Distributed Systems

Technical Stream Session 5:JGroups

CSC 253

Gordon Blair, François Taïani

Overview of the session
Overview of the Session

  • What is JGroups?

  • JGroups’ Architecture

    • The Channel Class

    • The Protocol Stack Infrastructure

    • The Building Blocks

  • Comparison with JMS

G. Blair/ F. Taiani

What is jgroups
What is JGroups?

  • A toolkit for reliable multicast communication

    • Open source (LGPL license from Free Software Foundation)

    • Implemented in Java

    • Used in industrial strength products like JBoss

      • to implement the JMS API, see last week TS lecture

  • Key Feature: Flexible Protocol Stack

    • Can be tailored to application needs and network characteristics

    • Can be extended

    • Provides a wide spectrum of properties. Focuses on reliability.

      • You only pay for what you really need

  • JGroups was created by Belan Ban when at Cornell Uni (US)

    • Incidentally the home of Isis (see group comm lecture last week)

    • Where Werner Vogel (Amazon’s CTO) worked for a long time

      • You know where to apply for your next summer job!

G. Blair/ F. Taiani

Jgroups architecture

higher level semantics

building blocks

fine tuning, adaptation, porting

protocol stacks

JGroups Architecture


socket like

Network (JVM Networking API)

G. Blair/ F. Taiani

Jgroups api channels

properties of the channel (see later)

sender's address (filled up by protocol stack)

all group members

I receive my own message

JGroups API: Channels

  • Design by Simplicity

    • One core class: org.jgroups.Channel


Message send_msg;Object recv_msg;Channelchannel=new JChannel(props);


send_msg=new Message(null, null, "Hello world");channel.send(send_msg);

recv_msg=channel.receive(0); System.out.println("Received " + recv_msg);


G. Blair/ F. Taiani

Protocol stacks
Protocol Stacks

  • Each Channel instance sits on top of a protocol stack

    • Stack content defined by the property string of the Channel:

    • Channel myChannel = new JChannel("LAYER1:LAYER2")

  • Protocol stack composed out of "layers"

    • Messages go up and down the layer stack

    • Each layer can modify, reorder, pass, drop oradd a header to messages











G. Blair/ F. Taiani

Protocol layers 1
Protocol Layers (1)

  • ChannelmyChan = new JChannel("UDP:PING:FD:GMS");

    • Stack contains layers UDP, PING, FD, and GMS (bottom-up)

    • Corresponds to classes: org.jgroups.protocols.UDP org.jgroups.protocols.PING org.jgroups.protocols.FD org.jgroups.protocols.GMS

    • UDP: IP multicast transport based on UDP

    • PING: initial membership (used by GMS)

    • FD: Failure detection (heartbeat protocol)

    • GMS: Group membership protocol.

  • Some expertise needed

    • Syntactically any combination possible

    • Does not necessarily make sense

      • For instance GMS does not work w/o PING






G. Blair/ F. Taiani

Protocol layers 2
Protocol Layers (2)

  • Example of other protocol layers

    • CAUSAL: causal ordering layer using vector clocks

    • TOTAL: total ordering layer using a message sequencer

    • NAKACK: negative ACKs (NAKs), paired with positive ACKs

    • STABLE: computes the broadcast messages that are stable

    • PERF: measures time taken by layers to process a message

    • COMPRESS: compresses the payload of a message

  • Constrains must be obeyed

    • Usually same layers needed in all group members

      • Not always the case, see PERF for instance

    • Position constrains

      • PERF must be top

    • Dependencies

      • GMS needs PING, STABLE needs NAKACK

G. Blair/ F. Taiani

Building blocks

Building Blocks


Building Blocks

  • Channel class very simple

    • Similar to sockets, but group behaviour

    • Message based. No reply/request concept.

    • Active (pull-style) message reception

      • Explicit threading needed on top of channel for passive reception

  • Building Blocks (org.jgroups.blocks package)

    • Higher level classes on top of Channel

    • Provides higher level programming abstractions

  • Examples

    • PullPushAdapter: passive reception

    • RpcDispatcher: remote invocation

    • VotingAdapter:distributed voting

G. Blair/ F. Taiani

Pullpushadapter example
PullPushAdapter: Example

public class PullPushTest implements MessageListener {

public static void main(String args[]) throws ... {

Channelchannel=new JChannel();


PullPushAdapteradapter=new PullPushAdapter(channel);


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

System.out.println("Sending msg #" + i);

channel.send(new Message(null, null, "Hello "+ i));






public void receive(Message msg)

{ System.out.println("Received msg: " + msg); }


G. Blair/ F. Taiani

Small quizz
Small Quizz

  • Imagine 5processes execute the previous code

    • How many "Hello i" will be printed in total?

    • How many would this be with nprocesses?

  • First let's think about the "Hello 0" message

    • Process 1 sends it to all group members

    • All 5 members receive and print "Hello 0" from process 1

    • Process 2 sends it to all group member too

    • All 5 members receive and print "Hello 0" from process 2

    • Dito for process 3,4,5: As a whole 5x5 = 25

  • 10 "Hello i" messages: 250 as a whole!

  • Home exercise: general formulae with n processes

G. Blair/ F. Taiani


public class RpcDispatcherTest {

public int print(int number) { return number * 2; }

public static void main(String[] args) throws ... {

Channelchannel=new JChannel();



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


disp.callRemoteMethods(null,"print", new Integer(i),

GroupRequest.GET_ALL, 0);

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





G. Blair/ F. Taiani

Rpcdispatcher quizz
RpcDispatcher: Quizz

  • Assuming 3 processes execute the previous program

    • How many times will the print method be invoked?

  • Answer:

    • For each callRemoteMethods, print executed by all 3 processes

    • callRemoteMethods is called by all 3 processes

    • Total number of times print is invoked: 3x3 = 9

  • Previous code completely symmetric

    • Possible only to have one group member perform an invocation

    • One group member can act as a proxy to external clients

    • Clients may contact any of the group members

G. Blair/ F. Taiani

Rpcdispatcher 2
RpcDispatcher (2)

  • Provides “Group” Remote Procedure Call behaviour

    • Looks up the invoked method (here “print”)

    • In example collects answers from all group members

    • Each group member is potentially both a client and a server!

  • Not completely transparent

    • No stub or skeleton to hide remote invocation

    • Arguments passed as an array of Object

  • Return behaviour can be adapted

    • GET_ABS_MAJORITY: return majority (of all members, may block)

    • GET_ALL: return all responses

    • GET_FIRST: return only first response

    • GET_MAJORITY: return majority (of all non-faulty members)

    • GET_N: return n responses (may block)

G. Blair/ F. Taiani

Comparison with jms
Comparison with JMS

  • JMS is a standardised API

    • Various implementations

  • JGroups is a library

    • Has its own API (not JMS compliant)

    • Only one implementation

    • Can be (and is) used to implement the JMS API (in JBoss)

  • JMS is a Message Oriented Middleware

    • Higher level that plain group communication as in JGroups

    • E.g. persistence, durability, transactions

  • JMS assumes a server based architecture

    • JGroups can be used in fully decentralised manner (or not)

G. Blair/ F. Taiani

To dig further
To Dig Further

  • The JGroups Web site


  • JGroups-ME: JGroups for mobile devices


G. Blair/ F. Taiani

Expected learning outcomes
Expected Learning Outcomes

At the end of this 5th Technical Session:

  • You should know what JGroups is about

  • You should appreciate the basic working of the Channel class

  • You should understand JGroups’ protocol stack mechanism

  • You should be able to compare JGroups to JMS

G. Blair/ F. Taiani