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[https://issues.jboss.org/browse/JGRP-886]
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 http://belaban.blogspot.ch/2015/07/a-new-nio.html.
Fork channels now support state transfer[https://issues.jboss.org/browse/JGRP-1941]
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[https://issues.jboss.org/browse/JGRP-1943]
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[https://issues.jboss.org/browse/JGRP-1940]
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[https://issues.jboss.org/browse/JGRP-1949]
Caused by a conversion from nanos to millis.
TCPPING: access initial_hosts in the defined order[https://issues.jboss.org/browse/JGRP-1959]
Was not the case as we used a HashSet which reordered elements.
SWIFT_PING: support JSON[https://issues.jboss.org/browse/JGRP-1954]
Request/response format has changed from application/xml to application/json in the Identity API.
The manual is at http://www.jgroups.org/manual/index.html.
The complete list of features and bug fixes can be found at http://jira.jboss.com/jira/browse/JGRP.
Bela Ban, Kreuzlingen, Switzerland, Sept 2015