Multiple consumers per session on JMS topic?

[noky]

I'd like to know if there is a preferred way to deal with the following situation. The scenario: using a JMS topic to broadcast data coming from multiple devices (about 10,000), each with a unique id. Different applications need to listen for messages from different sets of devices (up to several thousand). Is it preferable for each application to:

A) Create a single MessageConsumer from a Session with a large messageSelector String (eg: "deviceId IN ('1000', '1001', ... , '3000')" or

B) Create multiple MessageConsumers from a Session, each using a small messageSelector String (eg: "deviceId='1001')

There seems to be intermittent/random problems doing A), when the messageSelector string gets to be really large, say over about 4000 characters. In this case, the HornetQ backend sometimes delivers messages to a consumer where deviceId is not actually in the messageSelector String. I'm wondering if this is not the intended way to listen for a messages from a large number of specific sources.

Thanks!

[jbertram]

I would expect even a really large selector to work properly (albeit perhaps slowly).  Do you have a reproducible test-case you can share?

Also, what version are you using?

[noky]

Currently using 2.2.20GA. Admittedly, this version is a little old. Though, I haven't seen any reports of changes with regard to selectors since HORNETQ-545 (where I first reported problems in this arena)

I don't have a test case, the problem is intermittent. Here's what I've seen:

* Application X creates a MessageConsumer using a really large messageSelector String, eg: "deviceId IN ('1000', '1001', ... , '3000')

* Application Y creates a MessageConsumer with a small messageSelector String, eg: "deviceId IN ('4000')"

* Result: sometimes, but not always, Application Y gets a message where deviceId != 4000

Should I be using approach B) that I mentioned above? What is preferable?

[clebert.suconic]

you don't have anything else in your string that would silently fail? It would be interesting to get a testcase on that.

B would work as long as you don't do multi-threading within the same session (i.e. respect session-thread boundaries).

[noky]

Interesting point about a corrupt search string. Though, wouldn't session.createConsumer(topic, messageSelector) fail outright if the selector string was invalid/corrupt? Also, the consumers do seem to get the correct messages most of the time, it is only once in a while that an error happens (consumer gets message that does not match what was requested in the messageSelector)

I will see if I can put a test case together.

In general, though, regarding strategy A (single consumer, large message selector) vs strategy B (many consumers with simple message selector), do you have a sense of which is preferable? What are the tradeoffs of each? I realize this is likely to be highly implementation specific.

[clebert.suconic]

It's hard for me to tell without knowing the details of your usecase. I would avoid at all costs a big filter like this. I would maybe use groups on my business case or something like that.. and have a class without filters.. or with a minimal filter.

But if you really have to do it this way... then that's it.. I'm just saying how I would do it... but without real knowledge of your case... I only have these concepts I would try to follow.