3 Replies Latest reply on Dec 12, 2012 2:33 PM by clebert.suconic

    Dynamic Topic Selectors

    mackerman
    mackerman Dec 11, 2012 7:08 PM

      HI, I have a scenario where I have multiple servers each with a topic, each server consumes messages from each other server.  In general, each server will only be interested in a subset of the messages, the subset will change dynamically and frequently.  I would like to set selectors to reduce network traffic, but it appears that selectors can only be set when creating a consumer.  I would prefer not to recreate the consumers whenever the selector set changes - I would expect this to be expensive and cumbersone.

       

      Is there a way to dynamically change a consumer's selector?  Is there a better way to acheive what I want?

       

      thanks, Mitchell

      • 365 Views
      • Tags:
        • 1. Re: Dynamic Topic Selectors
          clebert.suconic
          clebert.suconic Dec 11, 2012 7:21 PM (in response to mackerman)

          if you are using hornetq-core api, you can create a queue with a filter or not, and then having multiple consumers with different filters.

           

           

          with JMS, you are currently bound to a single consumer / filter per subscription. That's a JMS limitation on the API.

            • Actions
          • 2. Re: Dynamic Topic Selectors
            mackerman
            mackerman Dec 12, 2012 12:23 PM (in response to clebert.suconic)

            thanks Clebert.  It doesn't look like these core filters can be dynamically changed however, they are setup on the queue or the consumer, and once setup can't be modified.  I would like to the change the filter expression frequently.  Or are you suggesting I setup multiple consumers each with a different filter?  That could be alot of consumers to dynamically manage.

              • Actions
            • 3. Re: Dynamic Topic Selectors
              clebert.suconic
              clebert.suconic Dec 12, 2012 2:33 PM (in response to mackerman)

              You would need to close the consumer and reopen it.

               

              Say...if we allowed you to close / reopen the consumer... the performance impact would be exactly the same. The implementation would have to re-scan the queues, and you would need a round trip on the network until the messages would arrive back to your client.

               

               

              My suggestion would be to keep the consumer as much as open as possible until you have to change the filter...

               

               

               

              And be careful if you're not using the message system as a database. That tends to fail usually.. if you need a lot of filtering you probably need a Cache System (Infinispan) or a Database system.

                • Actions