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.
s; local class incompatible: stream classdesc
serialVersionUID = -41264592145035
30426, local class serialVersionUID = -
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.
Can you send me (firstname.lastname@example.org) 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.
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.
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.
- 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.