Interoperability Azure Service Bus Message Queue Messages

Question

I have a Java App and a NodeJS App both using a single Azure Service Bus Message Queue.

I witness some strange effects with my clients, as follow.

JAVA MESSAGE PRODUCER (using QPID libraries per Azure JMS tutorial):

 TextMessage message = sendSession.createTextMessage();
        message.setText("Test AMQP message from JMS");
        long randomMessageID = randomGenerator.nextLong() >>>1;
        message.setJMSMessageID("ID:" + randomMessageID);
        sender.send(message);
        System.out.println("Sent message with JMSMessageID = " + message.getJMSMessageID());

OUTPUT: Sent message with JMSMessageID = ID:2414932965987073843

NODEJS MESSAGE CONSUMER:

serviceBus.receiveQueueMessage(queue, {timeoutIntervalInS: timeOut, isReceiveAndDelete: true}, function(err, message) {
if(message !==null)console.log(util.inspect(message, {showHidden: false, depth: null}));
});

OUTPUT:

{ body: '@\u0006string\b3http://schemas.microsoft.com/2003/10/Serialization/�\u001aTest AMQP message from JMS',
brokerProperties:
{ DeliveryCount: 1,
EnqueuedSequenceNumber: 5000004,
EnqueuedTimeUtc: 'Wed, 04 Nov 2015 21:28:21 GMT',
MessageId: '2414932965987073843',
PartitionKey: '89',
SequenceNumber: 59672695067659070,
State: 'Active',
TimeToLive: 1209600,
To: 'moequeue' },
contentType: 'application/xml; charset=utf-8' }

If I compare that to a message inserted into the queue via serviceBus.sendQueueMessage(), then the properties look like this:

{ body: 'test message',
brokerProperties:
{ DeliveryCount: 1,
EnqueuedSequenceNumber: 0,
EnqueuedTimeUtc: 'Wed, 04 Nov 2015 21:44:03 GMT',
MessageId: 'bc0a3d4f-15ba-434f-9fb0-1a3789885f8c',
PartitionKey: '734',
SequenceNumber: 37436171906517256,
State: 'Active',
TimeToLive: 1209600 },
contentType: 'text/plain',
customProperties:
{ message_number: 0,
sent_date: Wed Nov 04 2015 21:44:03 GMT+0000 (UTC) } }

So content type is different to start with - why? - and then where does the strange garbage in the body of the first message payload come from: @\u0006string\b3http://schemas.microsoft.com/2003/10/Serialization/�\u001a Is that the result of serialization? How can this be mitigated?

Find the code as well here: http://pastebin.com/T9RTFRBk

Answer 1

We have encountered the exact same issue, though in a somewhat more involved example using a Camel based producer. Due to changes in our environment we started to encounter these issues.

The issue here is how the REST service is interpreting the JMS message when it is encoding the HTTP response to the node client.

We've found that JmsTextmessage for some reason, not fully clear, are assumed to be of type "application/xml" and the content will be forwarded as such. Hence the OUTPUT you get in your example.

If instead using a JmsByteMessage, the content is interpreted as "application/octet-stream" and not mangled in transfer.

So try something along the lines of:

BytesMessage message = sendSession.createBytesMessage();
String body = "Test AMQP message from JMS";
message.writeBytes(body.getBytes(StandardCharsets.UTF_8));
sender.send(message);

We use this in order to transfer JSON encoded data to be interpreted by a Node.js client.