I'm trying to setup a HornetQ JMS bridge between HornetQ 2.0.0 and Websphere MQ 126.96.36.199.
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 message 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
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:
byte corrIDBytes = foreign.getJMSCorrelationIDAsBytes();
catch (JMSException e)
String corrIDString = foreign.getJMSCorrelationID();
if (corrIDString != null)
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 happen 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 processed 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. 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 because HornetQ is not able to re-read the same message afterward.
What's your opinion ? Is there anyway to solve this issue ?