5 Replies Latest reply on Jan 10, 2014 5:22 PM by Clebert Suconic

    Multiple consumers per session on JMS topic?

    Mike Charnoky Newbie

      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!

        • 1. Re: Multiple consumers per session on JMS topic?
          Justin Bertram Master

          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?

          • 2. Re: Multiple consumers per session on JMS topic?
            Mike Charnoky Newbie

            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?

            • 3. Re: Multiple consumers per session on JMS topic?
              Clebert Suconic Master

              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).

              • 4. Re: Multiple consumers per session on JMS topic?
                Mike Charnoky Newbie

                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.

                • 5. Re: Multiple consumers per session on JMS topic?
                  Clebert Suconic Master

                  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.