5 Replies Latest reply on Feb 21, 2008 8:34 AM by John Walton

    JBM 1.4.0.SP3 JMSX properties bug

    John Walton Newbie

      I've run into a problem using the bridge with a provider that is sending JMSX header properties (provider->bridge->JBoss JBM). The JMSX properties are NOT getting ignored.


      revision 2906, Thu Jul 19 11:07:43 2007 UTC introduced the following code:

      if (!propName.startsWith("JMSX") ||
      propName.equals("JMSXGroupID") ||
      propName.equals("JMSXGroupSeq")); <<<<<< NOTICE SEMI-COLON!
      msg.setObjectProperty(propName, entry.getValue());

      Additionally, in JBossMessage.java there is code that will throw an exception when a JMSX property is being set. This is causing a problem when using the bridge to write into another provider (JBoss JBM->bridge->provider). My question here is why is the JMSX property not ignored as the code in the bridge above intends to do?

      I've added code to catch this exception and ignore if to get it to work.

      JMSX exception thrown:

      15:44:28,870 WARN [Bridge] Failed to send + acknowledge batch, closing JMS obje cts
      javax.jms.JMSException: Can only set JMSXGroupId, JMSXGroupSeq, JMSXDeliveryCoun t
      at org.jboss.jms.message.JBossMessage.checkProperty(JBossMessage.java:11
      at org.jboss.jms.message.JBossMessage.setObjectProperty(JBossMessage.jav
      at org.jboss.jms.message.MessageProxy.setObjectProperty(MessageProxy.jav
      at com.evermind.server.jms.JMSUtils.convertProperties(JMSUtils.java:1760
      at com.evermind.server.jms.JMSUtils.convertHeaders(JMSUtils.java:1740)
      at com.evermind.server.jms.EvermindSession.send(EvermindSession.java:110
      at com.evermind.server.jms.EvermindMessageProducer.send(EvermindMessageP
      at com.evermind.server.jms.EvermindMessageProducer.send(EvermindMessageP
      at org.jboss.jms.server.bridge.Bridge.sendMessages(Bridge.java:1339)
      at org.jboss.jms.server.bridge.Bridge.sendBatchNonTransacted(Bridge.java
      at org.jboss.jms.server.bridge.Bridge.sendBatch(Bridge.java:1304)
      at org.jboss.jms.server.bridge.Bridge.access$15(Bridge.java:1282)
      at org.jboss.jms.server.bridge.Bridge$SourceListener.onMessage(Bridge.ja
      at org.jboss.jms.client.container.ClientConsumer.callOnMessage(ClientCon
      at org.jboss.jms.client.container.ClientConsumer$ListenerRunner.run(Clie
      at org.jboss.messaging.util.JBMExecutor$TCLExecutor.run(JBMExecutor.java
      at EDU.oswego.cs.dl.util.concurrent.QueuedExecutor$RunLoop.run(QueuedExe
      at java.lang.Thread.run(Thread.java:595)
      15:44:28,917 WARN [Bridge] Will retry after a pause of 5000 ms
      15:44:33,978 INFO [Bridge] Succeeded in reconnecting to servers


        • 1. Re: JBM 1.4.0.SP3 JMSX properties bug
          Tim Fox Master

          Thanks for the report. :)

          We'll get in fixed in the next release


          • 2. Re: JBM 1.4.0.SP3 JMSX properties bug
            John Walton Newbie


            Let me know if you want the source for the workaround I added. It's not ideal, but may assist to understand the problem.

            • 3. Re: JBM 1.4.0.SP3 JMSX properties bug
              Tim Fox Master

              Clearly the extra sem-colon is a bug.

              But regarding the issue of not allowing JMSX properties to be set:

              The JMS spec (1.1, section 3.5.8, table 3.3) makes it clear that the only JMSX properties that can be set by the client are JMSXGroupID and JMSXGroupSeq.

              So I think the current behaviour is correct.

              • 5. Re: JBM 1.4.0.SP3 JMSX properties bug
                John Walton Newbie

                Yes, this is related to the other issue. The Oracle provider is setting the JMSX properties which causes the exception within JBoss.

                My workaround was for JBoss is to ignore those properties and NOT throw the exception.


                public void setObjectProperty(String name, Object value) throws JMSException
                 if (JMS_JBOSS_SCHEDULED_DELIVERY_PROP_NAME.equals(name) && value instanceof Long)
                 this.scheduledDeliveryTime = ((Long)value).longValue();
                 // Ignore JMSX properties.
                 // Click Commerce workaround for using bridge with OC4J JMS Provider.
                 if (isJMSXProperty(name))
                 * Click Commerce workaround for using bridge with OC4J JMS Provider.
                 * Check the property name to see if it is a JMXS property. JMSX properties
                 * should not be propagated. This method is used to determine if the given property
                 * is eligable to be ignored.
                 * Note this method was introduced as a work around to JBoss JBM JIRA ticket See:
                 * http://jira.jboss.org/jira/browse/JBMESSAGING-1224
                 * Note checkProperty() will throw an exception when a JMSX propery is encountered.
                 * @param name the property name
                 * @return boolean true indicating the property is a JMSX property or
                 * false if the property is not a JMSX property.
                 boolean isJMSXProperty(String name)
                 if (name.startsWith("JMSX") &&
                 !name.equals("JMSXGroupID") &&
                 !name.equals("JMSXGroupSeq") &&
                 return true;
                 return false;

                This was used with Oracle Application Server 10.1.2