Thursday, September 03, 2015

JGroups 3.6.5 released

I'm happy to announce that 3.6.5 has been released !

One more patch release (3.6.6) is planned, and then I'll start working on 4.0 which will require Java 8. I'm looking forward to finally also being able to start using functional programming ! :-) (Note that I wrote my diploma thesis in Common Lisp back in the days...)

The major feature of 3.6.5 is certainly support for non-blocking TCP, based on NIO.2. While I don't usually add features to a patch release, I didn't want to create a 3.7.0, and I wanted users to be able to still use Java 7, and not require 8 in order to use the NIO stuff.

Here's a summary of the more important changes in 3.6.5:

TCP_NIO2: new non-blocking transport based on NIO.2


This new transport is based on NIO.2 and non-blocking, ie. no reads or writes will ever block. The biggest advantage compared to TCP is that we moved from the 1-thread-per-connection model to the 1-selector-for-all-connections model.
This means that we use 1 thread for N connections in TCP_NIO2, while TCP used N threads.
To use this, new classes TcpClient / NioClient and TcpServer / NioServer have been created.
More details at

Fork channels now support state transfer


Fork channels used to throw an exception on calling ForkChannel.getState(). This is now supported; details in the JIRA issue.

GossipRouter has been reimplemented using NIO


GossipRouter can now use a blocking (TcpServer) or a non-blocking (NioServer) implementation. On the client side, RouterStub (TUNNEL and TCPGOSSIP) can do the same, using TcpClient or NioClient.
Which implementation is used is governed by the -nio flag when starting the router, or in the configuration of TUNNEL / TCPGOSSIP (use_nio).
Blocking clients can interact with a non-blocking GossipRouter, and vice versa.

Retransmissions use the INTERNAL flag


Retransmissions use the internal flag: when a retransmission is a request, a potential response was also flagged as internal. This flag is now cleared on reception of a request.

Lock.tryLock() can wait forever


Caused by a conversion from nanos to millis.

TCPPING: access initial_hosts in the defined order


Was not the case as we used a HashSet which reordered elements.



Request/response format has changed from application/xml to application/json in the Identity API.

The manual is at

The complete list of features and bug fixes can be found at

Enjoy !

Bela Ban, Kreuzlingen, Switzerland, Sept 2015

1 comment:

  1. Update: note that there is a critical bug that I found thanks to the testing done by the Infinispan team (Dan): [1]. I'll release a 3.6.6 by Sept 10.