Performance : Filters vs Addresses

[jhohenstein]

I have a messaging application that is already built around the HornetQ Core API. I am currently investigating its design to add some features and to greatly increase its usage. For that reason, I am very interested in its performance characteristics.

The application has a fairly large number of different services behind the Bus. The number of those services is only going to increase. Currently, the addressing scheme used by clients of those services addresses messages using a scheme like:

"<service_name>.service"

e.g.

"chat.service"

I have been thinking that there could be benefits to filtering messages by message type and version.

Some services other than the chat service might be interested in a subset of all chat messages - e.g. "join room" but not "speak".

I would also like to be able to identify the handle different versions of services by indicating version in the message. This would require filtering the messages by version number.

The overriding question in my mind is whether this kind of filtering, by type, version, service, etc, is better done through HornetQ addresses or filters. I have read that in many JMS implementations the filtering expression is applied on the "client". I am concerned that, if I were to create very general addresses that the number of messages rejected with a filter on the client would far outweigh the number of messages retained.

Where are filters performed in HornetQ - on the client or on the Bus server?

[clebert.suconic]

Usually it's best if you create queues with filters... if you filter through a consumer, the consumer will perform lots of filter.match operations to return NO_MATCH, while if you route to a queue with a filter the filter.match is only performed once (at producing).

So, you will save CPU if you use Queues...

However this all depends on your throughput.. if you have a lot of messages per second is better to partition like I said... if performance doesn't matter (just a few messages / second) than consumer with a filter is fine.

[clebert.suconic]

(I believe this recommendation is generic to any message system BTW)