Will future releases be backwards compatible with older clie

[oliverhrdz]

My question pretty much says it all. Since we currently only have 1.0, and if we were to deploy JMS clients with the current client jar file, when subsequent versions of Messaging are released, will the clients require an updated jar to communicate with the new Messaging server?

[ovidiu.feodorov]

Normally, this shouldn't be necessary for minor versions (and even for major versions, see http://jira.jboss.org/jira/browse/JBMESSAGING-226). We have this in place for Messaging, and Remoting has this capability too.

However, I just noticed some backward compatibility problems with the last serialization release. For 1.0.1.CR2 I will make sure there are compatibity tests in place as part of the smoke test matrix, so compatibilty is not only something that should happen, but something that is tested.

[ovidiu.feodorov]

http://jira.jboss.org/jira/browse/JBMESSAGING-369

[oliverhrdz]

Sure enough, downloaded and installed 1.0.1CR1, and my client stopped working until I updated the client jar file. Got marshalling and serialization exceptions. I'm sure glad Messaging will attempt to keep backwards compatibility with older clients. Keep up the good work!

[oliverhrdz]

Luckily, my project has not yet upgraded production from JBossMQ to Messaging. We're back now to testing a new version of JBoss for JMS, and I found that CR5 is not backwards compatible. My 1.0.1CR4 client could not connect to the updated Messaging server, logging the following error:

java.lang.ExceptionInInitializerError
at sun.reflect.GeneratedSerializationConstructorAccessor50.newInstance(Unknown Source)
at java.lang.reflect.Constructor.newInstance(Constructor.java:494)
at org.jboss.serial.classmetamodel.ClassMetaData.newInstance(ClassMetaData.java:337)
at org.jboss.serial.persister.RegularObjectPersister.readData(RegularObjectPersister.java:239)
at org.jboss.serial.objectmetamodel.ObjectDescriptorFactory.readObjectDescriptionFromStreaming(ObjectDescriptorFactory.java:412)
at org.jboss.serial.objectmetamodel.ObjectDescriptorFactory.objectFromDescription(ObjectDescriptorFactory.java:82)
at org.jboss.serial.objectmetamodel.DataContainer$DataContainerDirectInput.readObject(DataContainer.java:634)
at org.jboss.serial.persister.RegularObjectPersister.readSlotWithFields(RegularObjectPersister.java:353)
at org.jboss.serial.persister.RegularObjectPersister.defaultRead(RegularObjectPersister.java:273)
at org.jboss.serial.persister.RegularObjectPersister.readData(RegularObjectPersister.java:241)
at org.jboss.serial.objectmetamodel.ObjectDescriptorFactory.readObjectDescriptionFromStreaming(ObjectDescriptorFactory.java:412)
at org.jboss.serial.objectmetamodel.ObjectDescriptorFactory.objectFromDescription(ObjectDescriptorFactory.java:82)
at org.jboss.serial.objectmetamodel.DataContainer$DataContainerDirectInput.readObject(DataContainer.java:634)
at org.jboss.serial.persister.RegularObjectPersister.readSlotWithFields(RegularObjectPersister.java:353)
at org.jboss.serial.persister.RegularObjectPersister.defaultRead(RegularObjectPersister.java:273)
at org.jboss.serial.persister.RegularObjectPersister.readData(RegularObjectPersister.java:241)
at org.jboss.serial.objectmetamodel.ObjectDescriptorFactory.readObjectDescriptionFromStreaming(ObjectDescriptorFactory.java:412)
at org.jboss.serial.objectmetamodel.ObjectDescriptorFactory.objectFromDescription(ObjectDescriptorFactory.java:82)
at org.jboss.serial.objectmetamodel.DataContainer$DataContainerDirectInput.readObject(DataContainer.java:634)
at org.jboss.serial.io.JBossObjectInputStream.readObjectOverride(JBossObjectInputStream.java:163)
at java.io.ObjectInputStream.readObject(ObjectInputStream.java:343)
at org.jboss.remoting.serialization.impl.java.JavaSerializationManager.receiveObject(JavaSerializationManager.java:132)
at org.jboss.remoting.marshal.serializable.SerializableUnMarshaller.read(SerializableUnMarshaller.java:66)
at org.jboss.jms.server.remoting.JMSWireFormat.read(JMSWireFormat.java:422)
at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.versionedRead(MicroSocketClientInvoker.java:477)
at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.transport(MicroSocketClientInvoker.java:351)
at org.jboss.remoting.MicroRemoteClientInvoker.invoke(MicroRemoteClientInvoker.java:116)
at org.jboss.remoting.Client.invoke(Client.java:612)
at org.jboss.remoting.Client.invoke(Client.java:604)
at org.jboss.jms.client.delegate.DelegateSupport.invoke(DelegateSupport.java:112)
at org.jboss.jms.client.delegate.ClientConnectionDelegate$createSessionDelegate_6052335267724906805.invokeNext(ClientConnectionDelegate$createSessionDelegate_6052335267724906805.java)
at org.jboss.jms.client.container.StateCreationAspect.handleCreateSessionDelegate(StateCreationAspect.java:101)
at org.jboss.aop.advice.org.jboss.jms.client.container.StateCreationAspect1.invoke(StateCreationAspect1.java)
at org.jboss.jms.client.delegate.ClientConnectionDelegate$createSessionDelegate_6052335267724906805.invokeNext(ClientConnectionDelegate$createSessionDelegate_6052335267724906805.java)
at org.jboss.jms.client.container.ConnectionAspect.handleCreateSessionDelegate(ConnectionAspect.java:164)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.jboss.aop.advice.PerInstanceAdvice.invoke(PerInstanceAdvice.java:130)
at org.jboss.jms.client.delegate.ClientConnectionDelegate$createSessionDelegate_6052335267724906805.invokeNext(ClientConnectionDelegate$createSessionDelegate_6052335267724906805.java)
at org.jboss.jms.client.container.ClosedInterceptor.invoke(ClosedInterceptor.java:134)
at org.jboss.aop.advice.PerInstanceInterceptor.invoke(PerInstanceInterceptor.java:117)
at org.jboss.jms.client.delegate.ClientConnectionDelegate$createSessionDelegate_6052335267724906805.invokeNext(ClientConnectionDelegate$createSessionDelegate_6052335267724906805.java)
at org.jboss.jms.client.container.ExceptionInterceptor.invoke(ExceptionInterceptor.java:69)
at org.jboss.jms.client.delegate.ClientConnectionDelegate$createSessionDelegate_6052335267724906805.invokeNext(ClientConnectionDelegate$createSessionDelegate_6052335267724906805.java)
at org.jboss.jms.client.container.ClientLogInterceptor.invoke(ClientLogInterceptor.java:107)
at org.jboss.jms.client.delegate.ClientConnectionDelegate$createSessionDelegate_6052335267724906805.invokeNext(ClientConnectionDelegate$createSessionDelegate_6052335267724906805.java)
at org.jboss.jms.client.delegate.ClientConnectionDelegate.createSessionDelegate(ClientConnectionDelegate.java)
at org.jboss.jms.client.JBossConnection.createSessionInternal(JBossConnection.java:255)
at org.jboss.jms.client.JBossConnection.createQueueSession(JBossConnection.java:165)
at mil.navy.erm.jms.JMSConnection$QueueSessionRequest.createSession(JMSConnection.java:959)
at mil.navy.erm.jms.JMSConnection$QueueSessionRequest.createSession(JMSConnection.java:931)
at mil.navy.erm.jms.JMSConnection$SessionRequest.requestSession(JMSConnection.java:899)
at mil.navy.erm.jms.JMSConnection.getQueueSession(JMSConnection.java:417)
at InboundTransProcessor.run(InboundTransProcessor.java:95)
at java.lang.Thread.run(Thread.java:595)
Caused by: java.lang.RuntimeException: java.lang.IndexOutOfBoundsException: Index: 0, Size: 0
at org.jboss.aop.advice.AdviceFactory.create(AdviceFactory.java:72)
at org.jboss.aop.Advisor.createInterceptorChain(Advisor.java:646)
at org.jboss.aop.Advisor.pointcutResolved(Advisor.java:916)
at org.jboss.aop.Advisor.resolveMethodPointcut(Advisor.java:678)
at org.jboss.aop.ClassAdvisor.createInterceptorChains(ClassAdvisor.java:604)
at org.jboss.aop.ClassAdvisor.access$300(ClassAdvisor.java:82)
at org.jboss.aop.ClassAdvisor$1.run(ClassAdvisor.java:299)
at java.security.AccessController.doPrivileged(Native Method)
at org.jboss.aop.ClassAdvisor.attachClass(ClassAdvisor.java:271)
at org.jboss.aop.AspectManager.initialiseClassAdvisor(AspectManager.java:587)
at org.jboss.aop.AspectManager.getAdvisor(AspectManager.java:575)
at org.jboss.jms.client.delegate.ClientSessionDelegate.<clinit>(ClientSessionDelegate.java)
... 57 more
Caused by: java.lang.IndexOutOfBoundsException: Index: 0, Size: 0
at java.util.ArrayList.RangeCheck(ArrayList.java:546)
at java.util.ArrayList.get(ArrayList.java:321)
at org.jboss.aop.advice.PerVmAdvice.generateInterceptor(PerVmAdvice.java:118)
at org.jboss.aop.advice.PerVmAdvice.generateOptimized(PerVmAdvice.java:52)
at org.jboss.aop.advice.AdviceFactory.create(AdviceFactory.java:68)
... 68 more

I'm suspecting from the above stack trace the issue is with Remoting. I notice the jboss-remoting.jar files are different in each version of the messaging.sar. Is this a Remoting issue?

[clebert.suconic]

Just double checking, I assume you didn' t have an issue when you updated your client?

[timfox]

Oliver-

JBoss Messaging won't be giving any compatibility guarantees until after the 1.2 GA release.

We put this to a public vote some time ago, and based the decision on that.

Please see

http://www.jboss.com/index.html?module=bb&op=viewtopic&t=85729

Sorry for any inconvenience caused.

[oliverhrdz]

Just double checking, I assume you didn' t have an issue when you updated your client?

Right, I intentionally did not update my client jar to test backwards compatibility. Once I did, my client and server connected fine.

Tim, I missed the vote on this issue. I got sidetracked from upgrading our JBoss server on my project with the US Navy, and am now back to researching our upgrade options. Backwards compatibility is a major issue for us, as our clients are onboard ships, and upgrading them in tandem with the server is unfeasible.

[timfox]

Is the system already live?

I mean is it an option for you to wait until 1.2 when we will have compatibility?

[ovidiu.feodorov]

Oliver,

Dropping insuring compatibility is a decision that we reluctantly took after we evaluated our resources and polled the community (http://www.jboss.com/index.html?module=bb&op=viewtopic&t=85729). Given the pace at which the code changes on the head, it is simply not feasible to maintain backward compatibility through all intermediate changes until 1.2.GA. Technically, it can done, the wire format has built-in support for it, but then we would have had to delay the delivery of 1.2, and since there are a lot of people who are waiting for clustering, we decided to temporarily drop the requirement.

The framework for testing backward/forward compatibility exists (take a look at tests/smoke/build.xml) and it was integrated within the release procedure, it is just temporarily disabled now.

We will be back at guaranteeing compatibility starting with 1.2.GA.

We do apologize for any inconvenience this may caused you. If you have a support contract with us, and you already have production clients deployed, we could evaluate what it implies to restore server compatibility in your specific case, as part of a consulting engagement. If you are interested, we can continue this discussion off-line.