Compatability between HQ (JMS) client and server libraries

[aengineer]

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

[clebert.suconic]

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.

[aengineer]

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

[clebert.suconic]

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.

[andy.miller]

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.

[aengineer]

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

[andy.miller]

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.