6 Replies Latest reply on Jan 30, 2012 7:25 AM by leosbitto

    Queue/Topic based distribution

    yairogen

      Hi,

       

      If I have multiple processes that want to listen on the same Queue, as queues are peer-to-peer will hornetQ know how to distribute the messages between my client processes?

       

      Does the same answer for the above apply to durable subscribers registering with the same client-id?

       

      Thanks,

       

      Yair

        • 1. Re: Queue/Topic based distribution
          leosbitto

          Yair Ogen wrote:

           

          If I have multiple processes that want to listen on the same Queue, as queues are peer-to-peer will hornetQ know how to distribute the messages between my client processes?

           

           

          Yes.

           

           

          Does the same answer for the above apply to durable subscribers registering with the same client-id?

           

           

          No. Durable subscribers are allowed only for topic (not for queue). Additionally, it is not allowed to have multiple durable subscribers with the same client-id.

          1 of 1 people found this helpful
          • 2. Re: Queue/Topic based distribution
            yairogen

            Thanks.

             

            In case of Topic - what are the best practices if I want to have 2 active active topic consumers? I would like to somehow create the same mechanism as queue distribution. Have 2 or more identical durable subscribers (i.e. the use same client id - as they are 2 instances of the same software) that are getting messages alternatly.

             

            I assume this is a "known" industry problem. Whar are the best practices here?

             

            regards,

             

            Yair

            • 3. Re: Queue/Topic based distribution
              leosbitto

              Yair Ogen wrote:

               

              In case of Topic - what are the best practices if I want to have 2 active active topic consumers? I would like to somehow create the same mechanism as queue distribution. Have 2 or more identical durable subscribers (i.e. the use same client id - as they are 2 instances of the same software) that are getting messages alternatly.

               

              I assume this is a "known" industry problem. Whar are the best practices here?

               

               

              Well, I certainly cannot speak for the "industry" (whatever that means). But in my previous experience we have abandoned the idea of topics at all and use only queues. The main reason is that when we need reliable message delivery with topics, we must use durable subscribers. The fact that there is no standardized management of durable subscribers specified in JMS leads to the current situation when various JMS providers have various capabilities of various quality. Additionally there is the limitation that only one session of a durable subscriber can be active at any time, which can lead to performance problems.

              • 4. Re: Queue/Topic based distribution
                yairogen

                I see what you mean and I agree. However, if you do need pub/sub capabilities because you have multiple clients that need to get the same message, what do you do? Send the same message to different queues? Use Queue Browser maybe?

                 

                Any other ideas?

                 

                Thanks,

                 

                Yair

                • 5. Re: Queue/Topic based distribution
                  ataylor

                  In reality Topics dont actually exist in the HornetQ server, this is just a facade we have on the client side. Think of a topic as an address with n queues (this is your subscription) each with its own consumer. Now, if you use the core API you should be able to get a pub/sub type capability.

                  • 6. Re: Queue/Topic based distribution
                    leosbitto

                    Yair Ogen wrote:

                     

                    ... multiple clients that need to get the same message, what do you do? Send the same message to different queues?

                     

                    Exactly this way. I woud actually suggest adding an extra abstraction layer (interface), which allows sending data somewhere (not only to a JMS queue). Then you can implement this interface to send the message to the JMS queue, and you can use the composite pattern to achieve sending to multiple queues, too. Combine this with some kind of properly configurable dependency injection framework, and everything becomes only a configuration issue...