Tuesday, October 21, 2014

JGroups 3.6.0.Final released

I just released 3.6.0.Final to SourceForge [1] and Nexus. It contains a few new features, but mostly optimizations and a few bug fixes. It is a small release before starting work on the big 4.0.

A quick look over what was changed:


New features


CENTRAL_LOCK: lock owners can be node rather than individual threads

[https://issues.jboss.org/browse/JGRP-1886]

Added an option to make the node the lock owner rather than the combo node:thread. This was needed by the JGroups clustering plugin for vert.x.


RSVP: option to not block caller

[https://issues.jboss.org/browse/JGRP-1851]

This way, a caller knows that its message will get resent, but it doesn't have to block. Also added code to skip RSVP if the message was unicast and UNICAST3 was used as protocol (only used for multicast messages).


Docker image for JGroups

[https://issues.jboss.org/browse/JGRP-1840]

mcast: new multicast diagnosis tool

[https://issues.jboss.org/browse/JGRP-1832]




Optimizations


UNICAST3 / NAKACK2: limit the max size of retransmission requests

[https://issues.jboss.org/browse/JGRP-1868]

When we have a retransmission request in UNICAST3 or NAKACK2 for a large number of messages, then the size of the retransmit message may become larger than what the transport can handle, and is therefore dropped. This leads to endless retransmissions.

The fix here is to retransmit only the oldest N messages such that the retransmit message doesn't exceed the max bundling size of the transport and to use a bitmap to identify missing messages to be retransmitted.

Also, the bitmaps used by SeqnoList reduce the size of a retransmission message.


Channel creation has unneeded synchronization

[https://issues.jboss.org/browse/JGRP-1887]

Slowing down parallel creation of many channels; this was removed.


UNICAST3: sync receiver table with sender table

[https://issues.jboss.org/browse/JGRP-1875]

In some edge cases, a receiver would not sync correctly with a sender.



Bug fixes





JMX: unregistering a channel which didn't register any protocols issues warnings

[https://issues.jboss.org/browse/JGRP-1894]


UDP: ip_ttl was ignored and is always 1

[https://issues.jboss.org/browse/JGRP-1880]


MERGE3: in some cases, the information about subgroups is incorrect

[https://issues.jboss.org/browse/JGRP-1876]

The actual MergeView was always correct, but the information about subgroups wasn't.


RELAY2 doesn't work with FORK

[https://issues.jboss.org/browse/JGRP-1875]


Enjoy !


[1] http://sourceforge.net/projects/javagroups/files/JGroups/3.6.0.Final/

Monday, October 06, 2014

JGroups and Docker

I've uploaded an image with JGroups and a few demos to DockerHub [2].

The image is based on Fedora 20 and contains JGroups, plus a few scripts which run a chat demo, a distributed lock demo and a distributed counter demo.

To run this, it's as simple as executing

docker run -it belaban/jgroups

This will drop you into a bash shell and you're ready to run any of the three demos.

Start multiple containers and you have a cluster in which you can try out things, e.g. a cluster node acquiring a lock, another node trying to acquire it and blocking, the first node crashing and the second node finally acquiring the lock etc.

Note that this currently runs a cluster on one physical box. I'll still need to investigate what needs to be done to run Docker containers on different hosts and cluster them [3].

The Dockerfile is at [1] and can be used to derive another image from it, or to build the image locally.

[1] https://github.com/belaban/jgroups-docker

[2] https://registry.hub.docker.com/u/belaban/jgroups/

[3] https://issues.jboss.org/browse/JGRP-1840