I am trying to send a simple string message from .NET to a Java client using amqp over the azure service bus. According to the documentation I should be able to send a brokered message like this:
message = new BrokeredMessage("this is a text string");
and have it show up in the Java client as a TextMessage (javax.jms.TextMessage). However when I try and cast the message in Java as a TextMessage I get an exception saying it cant convert a jms.impl.BytesMessageImpl to a TextMessage. Anyone know why the message looks like a BytesMessage rather than a TextMessage?
According to the docs a BytesMessage would be built like this:
byte[] bytes = { 33, 12, 45, 33, 12, 45, 33, 12, 45, 33, 12, 45 };
message = new BrokeredMessage(bytes);
which I am not doing....
Anyone know how to do something like this?
[Update] Interestingly, I tested my sending code with and without the TransportType=Amqp designation in my connection string. I also verified the code while it was running that the MessagingFactory settings were also set to the correct Transport Type each time. No matter which Transport type I used the message arrives to my Java app as a BytesMessage. Looking at the bytes in the message reveals the same result no matter how the message is sent:
@ string 3http://schemas.microsoft.com/2003/10/Serialization/�&BLABLA this is a message
[UPDATE2] I figured out the root cause of my issue. In my setup I have a subscriber that is forwarding messages to a queue. It appears that this is where the messages are getting messed up. If I send an AMQP message directly to the queue it comes to my Java app as a TextMessage. If I send the message to my Topic via AMQP and it then gets forwarded to my queue via a subscriber (with a filter) it gets mangled into a BytesMessage.
So how do I get this to work properly? Is there a way to setup my subscriber that is forwarding to the queue so this works?
There’s currently a limitation to the Service Bus AMQP interoperability story when using forwarding rules. During the forwarding, the message is incorrectly being re-serialized using data contract serializer. We’ll address that problem and I’ll report back here when that’s been done. In the meantime, a possible workaround would be to use message properties to store the application data rather than the body. That is, use a string property on the message to store the salient information rather than using the body.
Best regards,
Dave.
Service Bus team