You shouldn't have any problems with that on JBoss Messaging 1.4.

I just ran a quick test where I had thousand subscribers and it ran without any problems.

When i say you shouldn't have any problems, I'm assuming you are designing your application well and you have considered resource usage on the server (max Openfiles set for the number of clients you will have, enough I/O and enough memory on the server and JVM).

If your consumers are local to the server, you should probably avoid ObjectMessage as Serialization will aways be something expensive (but that should be ok if your consumers are distributed. On the server side an ObjectMessage is just a ByteArray, but on the client that is using ObjectINputStream and if you have all the clients on the same server that will use more CPU power.

(Those recommendations will apply to any system you choose.. not just JBM)

that each subscriber will have a selector to only pull down messages that its interested in.

Yes.. never use that style of selector to filter user data.. That's a terrible anti-pattern. (this is true for any messaging style software you are ever going to use).

It seems like temporary queues, would be the best approach for you, maybe the QueueRequestor approach.

I'm not sure I agree with Clebert here.

Using multiple selectors on a single *queue* is generally considered an anti-pattern. This is because when a message is consumed the entire queue needs to be scanned to see if one matches.

However, using selectors on a *topic* is NOT considered an anti-pattern. Why? This is because the topic subscription will only accept messages that match the selector, therefore you know at consumption time that the subscription only contains matching messages and you don't need to scan anything.

This means selectors on a topic does not have the performance problems associated with selectors on queues.

Noelo - If you can explain your use case in more detail, that would be helpful.

"timfox" wrote:

However, using selectors on a *topic* is NOT considered an anti-pattern. Why? This is because the topic subscription will only accept messages that match the selector, therefore you know at consumption time that the subscription only contains matching messages and you don't need to scan anything.