4 Replies Latest reply on Aug 17, 2004 4:17 AM by Bela Ban

    Error in jgroups - Version compatibility problems in handlin

    Vijay Noronha Newbie

      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:
      s; local class incompatible: stream classdesc
      serialVersionUID = -41264592145035
      30426, local class serialVersionUID = -
      at java.io.ObjectStreamClass.initNonProxy
      at java.io.ObjectInputStream.readNonProxyDesc
      at java.io.ObjectInputStream.readClassDesc
      at java.io.ObjectInputStream.readOrdinaryObject
      at java.io.ObjectInputStream.readObject0
      at java.io.ObjectInputStream.readArray
      at java.io.ObjectInputStream.readObject0
      at java.io.ObjectInputStream.readObject
      at org.jgroups.protocols.pbcast.Digest.readExternal
      at org.jgroups.util.Marshaller.read(Marshaller.java:77)
      at org.jgroups.Message.readExternal(Message.java:489)
      at org.jgroups.protocols.UDP.handleIncomingUdpPacket
      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.

        • 1. Re: Error in jgroups - Version compatibility problems in han
          Bela Ban Master

          Can you send me (bela@jboss.com) 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.



          • 2. Re: Error in jgroups - Version compatibility problems in han
            Bela Ban Master

            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.


            • 3. Re: Error in jgroups - Version compatibility problems in han
              Vijay Noronha Newbie


              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.

              • 4. Re: Error in jgroups - Version compatibility problems in han
                Bela Ban Master

                - 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.