Better to filter JMS message by topic name or String Property?

Question

Using Apache ActiveMQ Artemis, is it preferred to have one topic with String properties used to differentiate them or many topics? e.g., should publishers do this:

jmsTemplate.convertAndSend("quotes", quote, m -> {
   m.setStringProperty("symbol", "MSFT");
   return m;
});

or this?

jmsTemplate.convertAndSend("quotes.MSFT", quote, m -> {
   m.setStringProperty("symbol", "MSFT");
   return m;
});

Note that I can not just do:

jmsTemplate.convertAndSend("quotes.MSFT", quote);

because I need the symbol property as default-last-value-key:

<address-setting match="quote.#">
  <retroactive-message-count>100000</retroactive-message-count>
  <default-last-value-key>symbol</default-last-value-key>
  <default-non-destructive>true</default-non-destructive>

There could be 100,000 symbols. Would it be terrible to have so many pub/sub topics created?

Most will have no subscribers but will retain the last value using Retroactive Addresses. I will have consumers in Java and Python (STOMP).

Answer 1

Generally speaking, there's nothing intrinsic about ActiveMQ Artemis that would necessarily push you one way or the other.

However, your use-case is rather unique with the retroactive-address + LVQ configuration. My concern here with using a single address is that if there really are 100,000 symbols and the last value for each symbol should be retained then the ring-queue backing the retroactive address will potentially need to be 100,000 messages deep which means that every time a subscription queue is created on that address then the broker will have to process all those messages. I expect that would be a significant burden on the broker.

Therefore, at this point I'd say that an address for each symbol is likely the best. Then the retroactive-message-count can be 1.

Ultimately my best advice would be to actually test these two different configurations with a production-like load and then choose the one that best fits your use-case in terms of performance, manageability, etc. The devil is always in the details with this sort of thing. There are too many moving parts and unspoken requirements to provide an authoritative recommendation in a context like this.