Is it recommended for or against, to implement more than one reader on a queue (each reader has its own Session), with each reader specifying a different value for a selector?
For example, one reader might have a selector of "Rule = 'a'"; a second reader might have a selector of "Rule = 'b'"
What I'm trying to accomplish is the ability to have multiple processor threads on the receiving end, each responsible for handing messages for its own 'rule', and to effectively have each rule's processor running in parallel, so that all rules appear to be processed at the same time.
I know the JMS spec says the behavior of multiple readers is unspecified.
EJBs and message-driven beans aren't an option for this problem.
Many selectors on one queue is slow.
Each receiver has to scan all messages looking for a match
on each receive()
If the rules are mutually exclusive a topic is preferable.
The selector is run during the publish to see who wants the
If the rules are not mutually exclusive you will process the message
more than once with a topic.