How distinguish different JMS text messages from the same queue?

Question

I have an AMQ queue I'm connecting to. The publisher is sending JMS TextMessage. The messages are of different types: foo-updated, bar-updated, baz-updated etc, all on the single queue.

The payload/message body is JSON for all types, and their schemas have significant overlap (but no direct type information).

The publishing team said "search the string/text of the message for foo, and if it's there, it's a foo-updated message".

That sounds wrong.

There may be header information in the JMS message I can use (I'm exploring that), but assuming I can influence (but not necessarily change anything), what's the best way to handle this ?

Do you need to process only a specific type of message? If not, what's stopping you from getting a message from the queue, looking at the body for the type information, and then processing the message accordingly? It's not clear from your question if/why you need to distinguish one type of message from another. — Justin Bertram
Sorry for missing that detail: Yes, I'm only interested in foo messages, and want to ignore bar and baz messages (and ignore them with the least amount of processing, because I expect this to be a high traffic topic/queue). — K5 User
How do you distinguish between the actual types? Is there a JSON field that disambiguates them? If there is, you could use JSON Path (example here cassiomolin.com/2016/07/13/…) to go find that specific node, rather than doing a hit-or-miss String search (which could lead to bad type determination if the text "foo" appears in a "baz-updated" message, for example). — Not a JD

Axel Podehl Axel Podehl · Accepted Answer · 2019-05-09T06:52:22

If you have influence over using JMS topics, you should use that. Just like REST URLs you could use topics to indicate resources and actions on those: foo/create, foo/update, bar/update Then the JMS Broker can help you to efficiently route different messages to difference consumers. E.g. one consumer subscribing to foo/* another to */update

If you are stuck with a queue, the publisher should add additional information as header properties, for example type=foo and action=update. Then your consumer can specify JMS selectors like "action = 'update'" to receive only some of the messages.

Otherwise you are actually stuck with looking into the content :-(

How distinguish different JMS text messages from the same queue?

2 Answers