The message selectors are run by the server
on each receive operation. The messages are
only indexed in JMSPriority order.
This can have bad performance if there
are large numbers of messages in the queue
that do not match the selector, especially
if the messages have been pushed out onto disk.
But like you say, configuring 1000 queues would
be a nightmare. This could be done programatically
using the MBean interface of the destination manager.
Maybe you can make use of temporary queues and
the JMSReplyTo property?
I light of your reply. I was thinking that I could set up a fixed number of queues - say maybe 10 - and assign client id's to queues using a round robin algorithm.
This way the server would never have to sloth thru any more than 100 selectors in any one queue. Does this sound like a feasible idea from your perspective?
The way I envision this, the message sender would know which queue to publish to based on the range in which the client ID fell. Also, I would need a service to dole out client ID's.
If this does not seem practical. I would try to use a temporary message to solve this problem. However, I'm unclear on how to implement this. If the queue is temporary how will the message receivers know about the destination. If I could see an example of temporary queues it would be helpful.