Uploaded image for project: 'HornetQ'
  1. HornetQ
  2. HORNETQ-332

PropertyConversionException when reading messages from a HornetQ bridge with Websphere MQ

    Details

      Description

      I'm trying to setup a HornetQ JMS bridge between HornetQ 2.0.0 and Websphere MQ 6.0.2.5.

      A message is sent by an ESB instance to a HornetQ queue (hornetq-request-queue). A first HornetQ JMS bridge (front-2-back-bridge) consumes this message from this HornetQ queue and send it to a Websphere MQ queue (wmq-request-queue). In response to this message, a response message is sent to another Websphere MQ queue (wmq-response-queue). Then a second HornetQ JMS bridge (back-2-front-bridge) consumes this response message from this Websphere MQ queue and send them to another HornetQ queue (hornetq-response-queue).

      It was quite simple to setup all this but unfortunately, we have problems to re-read messages from the HornetQ queue containing response messages (hornetq-response-queue). As a matter of fact when the method getJMSCorrelationID() is called, HornetQ always returns the following exception

      Root Exception stack trace:
      org.hornetq.api.core.PropertyConversionException: Invalid conversion
      at org.hornetq.utils.TypedProperties.getSimpleStringProperty(TypedProperties.java:414)
      at org.hornetq.core.message.impl.MessageImpl.getSimpleStringProperty(MessageImpl.java:737)
      at org.hornetq.core.message.impl.MessageImpl.getStringProperty(MessageImpl.java:718)
      at org.hornetq.jms.client.HornetQMessage.getJMSCorrelationID(HornetQMessage.java:391)
      ...

      I've discovered that HornetQ uses the following code (in org.hornetq.jms.client.HornetQMessage) when a HornetQ bridge consumes this message and converts it to a HornetQ message:

      try

      { byte[] corrIDBytes = foreign.getJMSCorrelationIDAsBytes(); setJMSCorrelationIDAsBytes(corrIDBytes); }

      catch (JMSException e)
      {
      String corrIDString = foreign.getJMSCorrelationID();
      if (corrIDString != null)

      { setJMSCorrelationID(corrIDString); }

      }

      In my case, a byte array is built by Websphere MQ JMS implementation from the internal String representation of the correlation ID when the method foreign.getJMSCorrelationIDAsBytes() is called. As a consequence, the HornetQ message is constructed with a correlation ID as bytes. However, the HornetQ message would have been constructed with a correlation ID as String if the method foreign.getJMSCorrelationID() was called at first.

      When this HornetQ message is consumed by my ESB instance, a org.hornetq.api.core.PropertyConversionException is then thrown because HornetQ always expects a String value when the method foreign.getJMSCorrelationID() is called. That would have not been happened if the method foreign.getJMSCorrelationID() was called at first as explained previously.

      I think that this part of org.hornetq.jms.client.HornetQMessage must be completely re-thought and re-written accordingly to process this kind of issues.

      As far as I know, both methods getJMSCorrelationID() and getJMSCorrelationIDAsBytes() of javax.jms.Message (described in the JMS specifications version 1.1) could return null or throw a javax.jms.JMSException or java.land.UnsupportedOperationException. In my opinion, if a JMSCorrelationID is available as a String through getJMSCorrelationID(), HornetQ should always privilege that representation over the byte array representation of the correlation ID, eventually available though getJMSCorrelationIDAsBytes(). However, if only a byte array representation is available though getJMSCorrelationIDAsBytes(), HornetQ should throw a javax.jms.JMSException or java.land.UnsupportedOperationException because HornetQ is not able to re-read the same message afterward.

        Gliffy Diagrams

          Attachments

            Issue Links

              Activity

                People

                • Assignee:
                  timfox Tim Fox
                  Reporter:
                  bgillis Bertrand Gillis
                • Votes:
                  0 Vote for this issue
                  Watchers:
                  0 Start watching this issue

                  Dates

                  • Created:
                    Updated:
                    Resolved: