Error in jgroups - Version compatibility problems in handlin

[vbn77]

have come across a bug related to version
compatibility. We are using jgroups with jboss-cache.
We recently upgraded to version 2.2.3. However there
are still some machines on our network with an old jgroups
version - 2.2.0. Multicasting between these machines
throws the following error.

- exception=java.io.InvalidClassException:
org.jgroups.stack.IpAddres
s; local class incompatible: stream classdesc
serialVersionUID = -41264592145035
30426, local class serialVersionUID = -
1999612243427863834
at java.io.ObjectStreamClass.initNonProxy
(ObjectStreamClass.java:463)
at java.io.ObjectInputStream.readNonProxyDesc
(ObjectInputStream.java:1521)
at java.io.ObjectInputStream.readClassDesc
(ObjectInputStream.java:1435)
at java.io.ObjectInputStream.readOrdinaryObject
(ObjectInputStream.java:1626)
at java.io.ObjectInputStream.readObject0
(ObjectInputStream.java:1274)
at java.io.ObjectInputStream.readArray
(ObjectInputStream.java:1603)
at java.io.ObjectInputStream.readObject0
(ObjectInputStream.java:1271)
at java.io.ObjectInputStream.readObject
(ObjectInputStream.java:324)
at org.jgroups.protocols.pbcast.Digest.readExternal
(Digest.java:430)
at
org.jgroups.protocols.pbcast.STABLE$StableHeader.readE
xternal(STABLE.java:512)
at org.jgroups.util.Marshaller.read(Marshaller.java:77)
at org.jgroups.Message.readExternal(Message.java:489)
at org.jgroups.protocols.UDP.handleIncomingUdpPacket
(UDP.java:666)
at org.jgroups.protocols.UDP.run(UDP.java:242)
at java.lang.Thread.run(Thread.java:534)

This is a marshalling error due to a change in classes between versions.
There is a check in org.jgroups.Protocol.UDP.java -> run() (receiving of
multicast packets. There is a call to handle the Incoming Udp Packet using either the incoming packet handler in a different thread or calling handleIncomingUdpPacket() which eventually throws the error. I saw a check for different versions, right before this call. The problem seems to be the above call even though versions are different. I added a check to not handle the incoming packet and discard if there is a version mismatch and things were working fine..

I am also not clear of the implications of making this change as i didn't get any time to follow the exact flow and whether it affects
anything. Is this a valid bug. Will there be a plan to fix. I
am in immediate need of a fix as this message keep
dumping to our console and log - disabling the log is a
solution as this appears to be a harmless error, but is there a cleaner solution.

[belaban]

Can you send me ([e-mail]) your patch ? I'll see whether this is a bug and, if so, apply the patch. I have actually tested this against different versions of JGroups, and it worked, so I'm a bit astonished that this would not be caught by the version check.

Regards,

Bela

[belaban]

Okay, this is as designed: someone should be able to use different versions of JGroups if they know that the versions will work with each other. Therefore I just log a warning, and *don't* discard the message.

Choose a different mcast address or port if you want to avoid these warnings.

Bela

[vbn77]

Bela:

Thanks for looking into the issue. I thought that this must be as per design. The way we use jgroups is that we have a protocol stack created and deployed with multiple versions of our software. We cannot expect clients to configure jgroups ports, etc when they deploy our app as our app itself has a lot things to configure. We rely on a default config with ports, etc and that works well for us. I know that this is our problem and we cannot expect a solution for that. But as far as version compatibility is concerned JGroups doesn't seem to be compatible and that manifests an error. This is why i suggested not to handle incoming packets if versions are different. We have a lot of machines with different jgroups versions and it is difficult to configure all of them. I think that, since the check is already made, why handle the incoming packet if different versions cannot handle each other.

On other issue that i found was with FD_SOCK. This uses port 10000 by default for listening - This is in the registered port range and can interfere with some tools like it did with backup services in my company. We used a different value, but it would be good to change all default start port values to something in a range listed by IANA - 49152 through 65535.

[belaban]

- Added discard_incompatibe_packets to UDP
- Modified start_port initial value in FD_SOCK.

Note that you can set start_port in FD_SOCK via properties.

Bela