6 Replies Latest reply on Sep 10, 2010 11:44 AM by Andrig Miller

    Compatability between HQ (JMS) client and server libraries

    Aspi Engineer Newbie

      We are using HQ 2.1.0.CR1 client side libraries to send/receive JMS messages from a HQ server 2.1.2.Final. And the JMS client fails with the exception:

       

      javax.jms.JMSException: Server and client versions incompatible
          at org.hornetq.core.protocol.core.impl.ChannelImpl.sendBlocking(ChannelImpl.java:287)
          at org.hornetq.core.client.impl.FailoverManagerImpl.createSession(FailoverManagerImpl.java:410)
          at org.hornetq.core.client.impl.ClientSessionFactoryImpl.createSessionInternal(ClientSessionFactoryImpl.java:1123)
          at org.hornetq.core.client.impl.ClientSessionFactoryImpl.createSession(ClientSessionFactoryImpl.java:849)
          at org.hornetq.jms.client.HornetQConnection.authorize(HornetQConnection.java:565)
          at org.hornetq.jms.client.HornetQConnectionFactory.createConnectionInternal(HornetQConnectionFactory.java:624)
          at org.hornetq.jms.client.HornetQConnectionFactory.createConnection(HornetQConnectionFactory.java:116)
          at com.putnam.jboss.queue.QueueSend.init(QueueSend.java:39)
          at com.putnam.jboss.queue.QueueSend.run(QueueSend.java:97)
          at com.putnam.jboss.queue.QueueSend.main(QueueSend.java:90)
      Caused by: HornetQException[errorCode=108 message=Server and client versions incompatible]

       

      Is this expected?

       

      Thanks

      Aspi Engineer

      Putnam Investments

        • 1. Re: Compatability between HQ (JMS) client and server libraries
          Clebert Suconic Master

          For now yes... (At least between your CR and 2.1.X)

           

          That will be improved on 2.1.3 (next release):

           

          https://jira.jboss.org/browse/HORNETQ-445

           

          We may still require updating clients between major releases. But we will accept the same client when it's on the same point release.

           

          Of course we may also require updating the client when there's a bug on the client jar, but at least we would accept connections from them.

          • 2. Re: Compatability between HQ (JMS) client and server libraries
            Aspi Engineer Newbie

            Hi Clebert,

             

            Is there a official policy on backward compatability?

             

            You indicated that backward compatability is not guaranteed across major versions. But that can be problematic if major releases are only a few months apart. So when HQ 3.0 comes out, would one be expected to upgrade all JMS clients which are using HQ 2.X libraries? With 100's of messaging clients, this becomes quite challenging if not impossible.

             

            I am going to post this question on formal Redhat support.

             

            And I agree, if there is a defect in the client jar, then absolutely the client needs to upgrade. But we should not have a situation where a client jar has a defect, and the solution is to require that individual client to upgrade, but also upgrade the HQ server to a new major release. Now, you have to upgrade all other clients.

             

            Thanks

            Aspi

            • 3. Re: Compatability between HQ (JMS) client and server libraries
              Clebert Suconic Master

              Aspi,

               

              We won't definitely have compatibility between 2.x and 3.x (at least not on the public releases).

               

              There are other factors to be considered however for you guys.. since you guys will be using EAP, and the value added on the EAP is to have the version you're using in production being supported and mantained for a few years.

               

              So I guess the best is to ask on the support forum, so support engineers and management may answer it to you directly.

              • 4. Re: Compatability between HQ (JMS) client and server libraries
                Andrig Miller Apprentice

                Aspi Engineer wrote:

                 

                Hi Clebert,

                 

                Is there a official policy on backward compatability?

                 

                You indicated that backward compatability is not guaranteed across major versions. But that can be problematic if major releases are only a few months apart. So when HQ 3.0 comes out, would one be expected to upgrade all JMS clients which are using HQ 2.X libraries? With 100's of messaging clients, this becomes quite challenging if not impossible.

                 

                I am going to post this question on formal Redhat support.

                 

                And I agree, if there is a defect in the client jar, then absolutely the client needs to upgrade. But we should not have a situation where a client jar has a defect, and the solution is to require that individual client to upgrade, but also upgrade the HQ server to a new major release. Now, you have to upgrade all other clients.

                 

                Thanks

                Aspi

                Aspi,

                 

                We do have an official policy on backward compatibility.  Community releases should generally follow that major release can break backward compatibility, and major.minor would not.  With community releases where they are not in a shipping product, those rules may be loosely followed though.

                 

                In regards to shipping, supported product versions, there are strict rules which can not be broken.  HornetQ is just now getting into our EAP product, so the product branch will follow the strict rules, which are for the lifecycle of the product (EAP 5.x is seven years), there are primarily only bug fixes and backward compatibility is strictly maintained.  There are cases where we do add features within the product lifecycle, but those features cannot break backward compatibility.  In many cases, where we have added features, we have configuration options to allow perfect backward compatibility, where the feature itself could change behavior.  Only between major releases, such as EAP 5 to EAP 6, can backward compatibility be broken.  So, as you can see, we have strict rules in place for shipping product, because that's exactly what a paying customer would expect.  In the case of community we follow roughly the same rules, but there can be exceptions, especially where the code has not been picked up by a product yet, which was the case for HornetQ until just recently.

                • 5. Re: Compatability between HQ (JMS) client and server libraries
                  Aspi Engineer Newbie

                  Hi Andrig,

                   

                  Thank you for your detailed response.

                   

                  Some of these discussions may be duplicated since I also have a ticket open with JBoss support. However can you help clarify one thing for me. You indicated that the EAP 5.X life cycle is 7 years, and that for 7 years full backward compatability will be maintained. What happens when a client wishes to upgrade to EAP 6.X? Specifically, when one is upgrading to EAP 6.X which most likely will ship with either HQ 3.X, or 4.X or some higher major release, would it be required to upgrade all JMS clients too?

                   

                  The reason this topic is so important to us is because we plan on using HQ for inter-process communication. We will have somewhere between 200-300 individual JMS clients, each one packaged with the HQ client side libraries. If backward compatibility was not maintained, then we would need to upgrade all of these clients, and more important, we would need to upgrade them together. For all purposes that is impossible. What if we had to rollback the JMS server side upgrade in the middle of a business day. Would we be forced to rollback all client's too?

                   

                  What I am hoping for is a policy that is not version based, but rather time based. So a policy that states HQ server version N will work with all prior versions of HQ libraries that have been released in the last 2/4/6 years. If the policy is version based, that is HQ server 3.X will not work with libraries from 2.X, then I am stuck. Since I cannot upgrade all of my clients in one sweep, I essentially cannot upgrade HQ ever. For any product like HQ where the bits/libraries from the product are distributed across 100's of clients, the policy has to allow for incremental upgrades of the clients. Any policy that forces the server and all clients be upgraded together is less than desired.

                   

                  Thanks
                  Aspi Engineer

                  Putnam Investments

                  • 6. Re: Compatability between HQ (JMS) client and server libraries
                    Andrig Miller Apprentice

                    Aspi Engineer wrote:

                     

                    Hi Andrig,

                     

                    Thank you for your detailed response.

                     

                    Some of these discussions may be duplicated since I also have a ticket open with JBoss support. However can you help clarify one thing for me. You indicated that the EAP 5.X life cycle is 7 years, and that for 7 years full backward compatability will be maintained. What happens when a client wishes to upgrade to EAP 6.X? Specifically, when one is upgrading to EAP 6.X which most likely will ship with either HQ 3.X, or 4.X or some higher major release, would it be required to upgrade all JMS clients too?

                     

                    The reason this topic is so important to us is because we plan on using HQ for inter-process communication. We will have somewhere between 200-300 individual JMS clients, each one packaged with the HQ client side libraries. If backward compatibility was not maintained, then we would need to upgrade all of these clients, and more important, we would need to upgrade them together. For all purposes that is impossible. What if we had to rollback the JMS server side upgrade in the middle of a business day. Would we be forced to rollback all client's too?

                     

                    What I am hoping for is a policy that is not version based, but rather time based. So a policy that states HQ server version N will work with all prior versions of HQ libraries that have been released in the last 2/4/6 years. If the policy is version based, that is HQ server 3.X will not work with libraries from 2.X, then I am stuck. Since I cannot upgrade all of my clients in one sweep, I essentially cannot upgrade HQ ever. For any product like HQ where the bits/libraries from the product are distributed across 100's of clients, the policy has to allow for incremental upgrades of the clients. Any policy that forces the server and all clients be upgraded together is less than desired.

                     

                    Thanks
                    Aspi Engineer

                    Putnam Investments

                    No problem Aspi.

                     

                    When a client upgrades to EAP 6, there may be the possibility that they would have to upgrade the clients as well.  Of course there is no guarantee that you would have too.

                     

                    In understanding your specific situation, I will take with our team internally, since the messaging team reports to me, and we will have a discussion about client compatibility.  I have seen this issue once before with another customer, and I understand it can be a painful problem.  Perhaps we can do something within our development upstream to facilitate the support of older clients so customers could do a rolling client upgrade.

                     

                    In fact, if you want to introduce a JIRA for rolling client upgrades, that would be a good thing.  Just having your needs documented in the JIRA would be good.