9 Replies Latest reply on Oct 4, 2006 4:47 PM by Ovidiu Feodorov

    Will future releases be backwards compatible with older clie

    Oliver Hernandez Newbie

      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?

        • 1. Re: Will future releases be backwards compatible with older
          Ovidiu Feodorov Master

          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.

          • 3. Re: Will future releases be backwards compatible with older
            Oliver Hernandez Newbie

            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!

            • 4. 1.0.1CR5 Not Backwards Compatible
              Oliver Hernandez Newbie

              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?

              • 5. Re: Will future releases be backwards compatible with older
                Clebert Suconic Master

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

                • 6. Re: Will future releases be backwards compatible with older
                  Tim Fox Master

                  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.

                  • 7. Re: Will future releases be backwards compatible with older
                    Oliver Hernandez Newbie

                     

                    "clebert.suconic@jboss.com" wrote:
                    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.

                    • 8. Re: Will future releases be backwards compatible with older
                      Tim Fox Master

                      Is the system already live?

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

                      • 9. Re: Will future releases be backwards compatible with older
                        Ovidiu Feodorov Master

                        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.