7 Replies Latest reply on Apr 29, 2010 10:39 AM by Tim Fox

    JMSBridge unable to process _HQ_DUP_ID headers

    Terry Paterson Newbie

      Hi Guys,

       

      We are using JMS and Core bridges between two servers on a LAN (ultimately we will be doing this over a WAN),

       

      at certain points JBoss/Hornet seems to be adding a _HQ_DUP_ID header to each message,

       

      and it seems that the JMSBridge is unable to process this header (or it's value),

       

      we get the following exception in the server.log on the consumer machine (which is running the JMSBridge) :

       

      2010-04-27 16:49:47,361 WARNING [org.hornetq.jms.bridge.impl.JMSBridgeImpl] (jmsbridge-source-receiver-thread) Failed to send
      + acknowledge batch, closing JMS objects
      javax.jms.MessageFormatException: class [B is not a valid property type
              at org.hornetq.jms.client.HornetQMessage.setObjectProperty(HornetQMessage.java:825)
              at org.hornetq.jms.bridge.impl.JMSBridgeImpl.copyProperties(JMSBridgeImpl.java:1695)
              at org.hornetq.jms.bridge.impl.JMSBridgeImpl.addMessageIDInHeader(JMSBridgeImpl.java:1638)
              at org.hornetq.jms.bridge.impl.JMSBridgeImpl.sendMessages(JMSBridgeImpl.java:1571)
              at org.hornetq.jms.bridge.impl.JMSBridgeImpl.sendBatchXA(JMSBridgeImpl.java:1497)
              at org.hornetq.jms.bridge.impl.JMSBridgeImpl.sendBatch(JMSBridgeImpl.java:1414)
              at org.hornetq.jms.bridge.impl.JMSBridgeImpl.access$1500(JMSBridgeImpl.java:64)
              at org.hornetq.jms.bridge.impl.JMSBridgeImpl$SourceReceiver.run(JMSBridgeImpl.java:1788)
      2010-04-27 16:49:47,372 WARNING [org.hornetq.jms.bridge.impl.JMSBridgeImpl] (jmsbridge-failurehandler-thread) Will retry after a pause of 50000 ms

       

       

      having attached a debugger - it appears that the value for the _HQ_DUP_ID header/property is a byte array,

       

       

      I'm guessing the _HQ_DUP_ID header is only added if the messages are paged or similar ?

       

      can we turn off this adding of the _HQ_DUP_ID header ?

       

      or if there a fix to the JMSBridge ?

       

       

      Thanks in advance

        • 2. Re: JMSBridge unable to process _HQ_DUP_ID headers
          Terry Paterson Newbie

          We have downloaded the latest from TRUNK using SVN, completed the build and copied the matching JAR files to our version of JBoss5 with HornetQ,

           

          {code}

          root@xeon lib # ls -l
          total 2004
          -rw-r--r-- 1 jboss users    5762 Mar 10 09:34 hornetq-bootstrap.jar
          -rw-r--r-- 1 jboss users 1007248 Mar 10 09:34 hornetq-core.jar
          -rw-r--r-- 1 jboss users   15320 Mar 10 09:34 hornetq-jboss-as-integration.jar
          -rw-r--r-- 1 jboss users  158109 Mar 10 09:34 hornetq-jms.jar
          -rw-r--r-- 1 jboss users    4864 Mar 10 09:34 hornetq-logging.jar
          -rw-r--r-- 1 jboss users   44119 Mar 10 09:34 hornetq-transports.jar
          -rw-r--r-- 1 jboss users  699044 Mar 10 09:34 netty.jar

           

          root@xeon lib # sudo cp /tmp/hornetq_trunk/hornetq-bootstrap.jar .
          root@xeon lib # sudo cp /tmp/hornetq_trunk/hornetq-core.jar .
          root@xeon lib # sudo cp /tmp/hornetq_trunk/hornetq-jboss-as-integration.jar .
          root@xeon lib # sudo cp /tmp/hornetq_trunk/hornetq-jms.jar .

          root@xeon lib # sudo cp /tmp/hornetq_trunk/hornetq-logging.jar .

           

          root@xeon lib # cd ../deploy/hornetq-ra.rar

           

          root@xeon hornetq-ra.rar # sudo jar xvf /tmp/hornetq_trunk/hornetq-ra.rar
            created: META-INF/
          inflated: META-INF/MANIFEST.MF
          inflated: META-INF/ra.xml
          inflated: hornetq-ra.jar
          inflated: hornetq-core-client.jar
          inflated: hornetq-jms.jar

          {code}

           

           

          there appeared to be no hornetq-transports.jar in the build/jars directory

           

          upon starting JBoss we observed the following exception :

           

          {code}

          2010-04-28 14:43:37,879 INFO  [org.hornetq.core.server.impl.HornetQServerImpl] (main) live server is starting..
          2010-04-28 14:43:37,981 INFO  [org.hornetq.core.persistence.impl.journal.JournalStorageManager] (main) Using AIO Journal
          2010-04-28 14:43:38,011 WARNING [org.hornetq.core.server.impl.HornetQServerImpl] (main) Security risk! It has been detected
          that the cluster admin user and password have not been changed from the installation default. Please see the HornetQ user
          guide, cluster chapter, for instructions on how to do this.
          2010-04-28 14:43:39,414 INFO  [org.hornetq.core.server.cluster.impl.BridgeImpl] (Thread-1 (group:HornetQ-server-threads4230
          140-1761233)) Connecting bridge outgoing-remote-workorder-bridge to its destination
          2010-04-28 14:43:39,414 INFO  [org.hornetq.core.server.cluster.impl.BridgeImpl] (Thread-0 (group:HornetQ-server-threads4230
          140-1761233)) Connecting bridge outgoing-pinnet-parts-bridge to its destination
          2010-04-28 14:43:39,524 ERROR [org.jboss.kernel.plugins.dependency.AbstractKernelController] (main) Error installing to Sta
          rt: name=JMSServerManager state=Create
          java.lang.AbstractMethodError
                  at org.hornetq.core.remoting.server.impl.RemotingServiceImpl.start(RemotingServiceImpl.java:200)
                  at org.hornetq.core.server.impl.HornetQServerImpl.start(HornetQServerImpl.java:315)
                  at org.hornetq.jms.server.impl.JMSServerManagerImpl.start(JMSServerManagerImpl.java:233)
                  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:597)
                  at org.jboss.reflect.plugins.introspection.ReflectionUtils.invoke(ReflectionUtils.java:59)
                  at org.jboss.reflect.plugins.introspection.ReflectMethodInfoImpl.invoke(ReflectMethodInfoImpl.java:150)
                  at org.jboss.joinpoint.plugins.BasicMethodJoinPoint.dispatch(BasicMethodJoinPoint.java:66)
                  at org.jboss.kernel.plugins.dependency.KernelControllerContextAction$JoinpointDispatchWrapper.execute(KernelControl
          lerContextAction.java:243)
                  at org.jboss.kernel.plugins.dependency.ExecutionWrapper.execute(ExecutionWrapper.java:47)
                  at org.jboss.kernel.plugins.dependency.KernelControllerContextAction.dispatchExecutionWrapper(KernelControllerConte
          xtAction.java:111)
                  at org.jboss.kernel.plugins.dependency.KernelControllerContextAction.dispatchJoinPoint(KernelControllerContextActio
          n.java:72)
                  at org.jboss.kernel.plugins.dependency.LifecycleAction.installActionInternal(LifecycleAction.java:221)
                  at org.jboss.kernel.plugins.dependency.InstallsAwareAction.installAction(InstallsAwareAction.java:54)
                  at org.jboss.kernel.plugins.dependency.InstallsAwareAction.installAction(InstallsAwareAction.java:42)
                  at org.jboss.dependency.plugins.action.SimpleControllerContextAction.simpleInstallAction(SimpleControllerContextAct
          ion.java:62)
                  at org.jboss.dependency.plugins.action.AccessControllerContextAction.install(AccessControllerContextAction.java:71)
                  at org.jboss.dependency.plugins.AbstractControllerContextActions.install(AbstractControllerContextActions.java:51)
                  at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
                  at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1633)
                  at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:935)
                  at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1083)
                  at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:985)
                  at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:775)
                  at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:540)
                  at org.jboss.deployers.vfs.deployer.kernel.BeanMetaDataDeployer.deploy(BeanMetaDataDeployer.java:121)
                  at org.jboss.deployers.vfs.deployer.kernel.BeanMetaDataDeployer.deploy(BeanMetaDataDeployer.java:51)
                  at org.jboss.deployers.spi.deployer.helpers.AbstractSimpleRealDeployer.internalDeploy(AbstractSimpleRealDeployer.ja
          va:62)
                  at org.jboss.deployers.spi.deployer.helpers.AbstractRealDeployer.deploy(AbstractRealDeployer.java:50)

                  at org.jboss.deployers.plugins.deployers.DeployerWrapper.deploy(DeployerWrapper.java:171)
                  at org.jboss.deployers.plugins.deployers.DeployersImpl.doDeploy(DeployersImpl.java:1440)
                  at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1158)
                  at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1179)
                  at org.jboss.deployers.plugins.deployers.DeployersImpl.install(DeployersImpl.java:1099)
                  at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
                  at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1633)
                  at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:935)
                  at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1083)
                  at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:985)
                  at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:823)
                  at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553)
                  at org.jboss.deployers.plugins.deployers.DeployersImpl.process(DeployersImpl.java:782)
                  at org.jboss.deployers.plugins.main.MainDeployerImpl.process(MainDeployerImpl.java:702)
                  at org.jboss.system.server.profileservice.repository.MainDeployerAdapter.process(MainDeployerAdapter.java:117)
                  at org.jboss.system.server.profileservice.repository.ProfileDeployAction.install(ProfileDeployAction.java:70)
                  at org.jboss.system.server.profileservice.repository.AbstractProfileAction.install(AbstractProfileAction.java:53)
                  at org.jboss.system.server.profileservice.repository.AbstractProfileService.install(AbstractProfileService.java:403
          )
                  at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
                  at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1633)
                  at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:935)
                  at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1083)
                  at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:985)
                  at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:775)
                  at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:540)
                  at org.jboss.system.server.profileservice.repository.AbstractProfileService.registerProfile(AbstractProfileService.
          java:308)
                  at org.jboss.system.server.profileservice.ProfileServiceBootstrap.start(ProfileServiceBootstrap.java:256)
                  at org.jboss.bootstrap.AbstractServerImpl.start(AbstractServerImpl.java:461)
                  at org.jboss.Main.boot(Main.java:221)
                  at org.jboss.Main$1.run(Main.java:556)
                  at java.lang.Thread.run(Thread.java:619)
          2010-04-28 14:43:39,688 WARN  [org.hornetq.integration.transports.netty.NettyConnector] (Thread-1 (group:HornetQ-server-thr
          eads4230140-1761233)) Unexpected Netty Version was expecting 3.2.0.BETA1-r2215 using 3.1.5.GA-r1772
          2010-04-28 14:43:39,688 WARN  [org.hornetq.integration.transports.netty.NettyConnector] (Thread-0 (group:HornetQ-server-thr
          eads4230140-1761233)) Unexpected Netty Version was expecting 3.2.0.BETA1-r2215 using 3.1.5.GA-r1772
          2010-04-28 14:43:39,689 DEBUG [org.hornetq.integration.transports.netty.NettyConnector] (Thread-0 (group:HornetQ-server-thr
          eads4230140-1761233)) Started Netty Connector version 3.1.5.GA-r1772
          2010-04-28 14:43:39,688 DEBUG [org.hornetq.integration.transports.netty.NettyConnector] (Thread-1 (group:HornetQ-server-thr
          eads4230140-1761233)) Started Netty Connector version 3.1.5.GA-r1772

          {code}

           

           

          we then downloaded netty version 3.2.0.BETA1 from the download page, and overwrote the existing lib/netty.jar,

          and once again restarted JBoss.

           

          and we still got the same exception as before,

           

          there does not appear to be another copy of netty.jar around.

           

           

           

           

           

           

          can you point us to some documentation regarding building from TRUNK and updating JBoss ?

           

           

          also -- we compared the source of JMSBridgeImpl.java, as well as PagingStoreImpl.java from TRUNK,

          and as far as we can tell - the code associated with setting / reading the _HQ_DUP_ID property has not changed ?

          so we assume the previous error is still present ?

          • 3. Re: JMSBridge unable to process _HQ_DUP_ID headers
            Clebert Suconic Master

            The transport was moved to core.

             

             

            You will also need to update your configuration. There are a bunch of changes made on the latest config file.

             

            The easier would be to get your changes and place it on a new file.

            • 4. Re: JMSBridge unable to process _HQ_DUP_ID headers
              Terry Paterson Newbie

              The transport was moved to core.

               

              I guess this means that lib/hornetq-transports.jar is no longer required as the classes are now in lib/hornetq-core.jar ?

              (so we can probably remove the hornetq-transports.jar)

               

              You will also need to update your configuration. There are a bunch of  changes made on the latest config file.

               

              The easier would be to get your  changes and place it on a new file.

               

               

              sorry, could you be a little more specific ?

               

              which files should we get/update and where from ?

               

              we can certainly make our own changes again (adding queues, topics, bridges, etc)..

               

              just not sure which files to replace, and where to get the new versions from ?

               

               

              Thanks

              • 5. Re: JMSBridge unable to process _HQ_DUP_ID headers
                Clebert Suconic Master

                "I guess this means that lib/hornetq-transports.jar is no longer required as the classes are now in lib/hornetq-core.jar ?

                (so we can probably remove the hornetq-transports.jar)"

                 

                 

                that's what I said... .hornetq-transposrts.jar doesn't exist any more.

                 

                 

                "sorry, could you be a little more specific ?"

                 

                 

                 

                Look at the config files (hornetq-configuration, hornetq-jms... etc)... We have made a few changes.  We have basically added a new connection factory (used for performance), and the connector and acceptors names have changed due to the move on the transports.

                 

                 

                We always ask users to use the latest configuration files.

                • 6. Re: JMSBridge unable to process _HQ_DUP_ID headers
                  Tim Fox Master

                  When you upgrade you need to follow the instructions as in the quick start guide.

                   

                  You can't just copy jars across.