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 MESSA
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.
I had the same issue with the message body being prefixed by this "@\u0006string\b3http://schemas.microsoft.com/2003/10/Serialization/\u0001".
I was using Nodejs, with the azure-iot-device-mqtt and azure-iot-device packages, to send messages to IoT hub. I was using a Stream Analytics Job to receive the messages from IoT hub and publish them to a queue. I was using Nodejs, with the amqp10 package, to receive the events from the queue.
The problem was not caused by the way I was sending or receiving the messages. Rather, the problem was with the Stream Analytics compatibility level! Compatibility level 1.0 (the default at least when I deployed) uses the DataContractSerializer which serializes the message into an XML stream! Microsoft changed (fixed) this with compatibility level 1.1. So you may just need to change the compatibility level (CONFIGURE->Compatibility level) for your Stream Analytics job to 1.1.
See: https://docs.microsoft.com/en-us/azure/stream-analytics/stream-analytics-compatibility-level#major-changes-in-the-latest-compatibility-level-11:
The Azure Service Bus supports two different protocols: AMQP and HTTP. The Java/JMS using qpid libs is using AMQP protocal for ServiceBus. However, the ServiceBus REST APIs wrapped in NodeJS thur HTTP protocol.
Details for AMQP support in Service Bus, please refer to https://azure.microsoft.com/en-us/documentation/articles/service-bus-amqp-overview/.
And for REST APIs of ServiceBus, please refer to https://msdn.microsoft.com/en-us/library/azure/hh780717.aspx.
AMQP is a binary, application layer protocol, designed to efficiently support a wide variety of messaging applications and communication patterns. - from WikiPedia
But the HTTP is a text protocol.
The message format is as below, please refer to the section Message Format
of the aritifact http://docs.oasis-open.org/amqp/core/v1.0/os/amqp-core-messaging-v1.0-os.html#section-message-format. And the AMQP specification can be refered to http://docs.oasis-open.org/amqp/core/v1.0/os/amqp-core-overview-v1.0-os.html.
Bare Message
|
.---------------------+--------------------.
| |
+--------+-------------+-------------+------------+--------------+--------------+--------+
| header | delivery- | message- | properties | application- | application- | footer |
| | annotations | annotations | | properties | data | |
+--------+-------------+-------------+------------+--------------+--------------+--------+
| |
'-------------------------------------------+--------------------------------------------'
|
Annotated Message
So the messages sent in Java or sent in NodeJS were serialized to different results.
The content \uXXXX
formated in the content of body from AMQP is Unicode Charater.
The Unicode Charater \u0006
is Acknowledge controll charater, please refer to https://en.wikipedia.org/wiki/Acknowledge_character to know it.
And the Unicode Charater \u001a
is Substitute controll charater, please refer to https://en.wikipedia.org/wiki/Substitute_character.
They are limit the start and end of the metadata in the message header.