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/
Forgot to mention: 3.6 was compiled with JDK 7, but if someone needs it to run under JDK 6, it will still compile, with the exception of mcast (which can be removed).
ReplyDeletemcast meaning multicast ?
ReplyDeleteNo, mcast is a class which replaces McastSenderTest and McastReceiverTest
ReplyDeleteHi Bela,
ReplyDeleteI have a simple Jgroups example which works fine with version 3.4.0 but gives an error on the latest version.
Could give me some hints?
The code is:
========================================================================================================================================================================================================================
import org.jgroups.*;
public class ReceiverTest extends ReceiverAdapter {
public static void main(String args[]) throws Exception {
Channel chan=new JChannel();
chan.connect("ReceiverTest");
chan.setReceiver(new ReceiverTest());
for(int i=0; i < 10; i++) {
System.out.println("Sending msg #" + i);
chan.send(new Message(null,null,"Hello "+ i));
Thread.currentThread().sleep(1000);
}
chan.close();
}
public void receive(Message msg)
{ System.out.println(msg.getObject());}
public void viewAccepted(View new_view) { System.out.println("** view: " + new_view); }
}
The error is:
========================================================================================================================================================================================================================
Nov 01, 2014 11:26:15 AM org.jgroups.logging.JDKLogImpl error
SEVERE: failed setting ip_ttl
java.lang.reflect.InvocationTargetException
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at org.jgroups.protocols.UDP.setTimeToLive(UDP.java:339)
at org.jgroups.protocols.UDP.createSockets(UDP.java:368)
at org.jgroups.protocols.UDP.start(UDP.java:270)
at org.jgroups.stack.ProtocolStack.startStack(ProtocolStack.java:965)
at org.jgroups.JChannel.startStack(JChannel.java:885)
at org.jgroups.JChannel._preConnect(JChannel.java:547)
at org.jgroups.JChannel.connect(JChannel.java:282)
at org.jgroups.JChannel.connect(JChannel.java:273)
at ReceiverTest.main(ReceiverTest.java:6)
Caused by: java.io.IOException: Method not implemented!
at java.net.DualStackPlainDatagramSocketImpl.setTimeToLive(Unknown Source)
... 13 more
-------------------------------------------------------------------
GMS: address=INC051000010-5007, cluster=ReceiverTest, physical address=fe80:0:0:0:b4e7:ae2d:6862:f8f9%11:51897
-------------------------------------------------------------------
Sending msg #0
Hello 0
Sending msg #1
Hello 1
Sending msg #2
Hello 2
Sending msg #3
Hello 3
Sending msg #4
Hello 4
Sending msg #5
Hello 5
Sending msg #6
Hello 6
Sending msg #7
Hello 7
Sending msg #8
Hello 8
Sending msg #9
Hello 9
This means JGroups failed to set UDP.ip_ttl in the transport. I assume you use Windows, as this method doesn't seem to be implemented. Other than having a (default) TTL of 1, this shouldn't cause any problems.
ReplyDeleteThere is scenario in my application where I want to execute JGroup application on different IPs on multiple boxes. Where I can configure those IPs. Those should be in UDP.xml or we will have to given as command line arguments. Is it being supported by JGroup or not.
ReplyDeleteThanks,
Chandra Mauli Tripathi