4

How to create/preconfigure durable subscriber(s) in activemq.xml so that these subscriptions are ready upon ActiveMQ comes up? As if subscribers are in the offline state.

We're expecting a fixed (yet configurable) number of known subscribers. Wanna buffer all msgs sent by the publisher starting day 1, in case not all subscribers are up. Not sure if this is a common scenario but thanks in advance for the help.

user1500049
  • 993
  • 7
  • 15
  • This is a common scenario for data-centric distributed systems and, as an FYI, your use-case is easily achieved when using an OMG DDS implementation using the Durability QoS. See [OMG Data Distribution Service portal](http://portals.omg.org/dds/) for more information. – Reinier Torenbeek Jul 04 '12 at 00:20

2 Answers2

6

This is a really common use case. What you should actually be looking at is composite destinations, rather than durable topics (there are loads of problems with this functionality, the main one being messages not being persisted by default and therefore not surviving broker outages).

Using this scheme you set up a composite topic to forward each message to a number of queues - a dedicated one per subscriber. 

<destinationInterceptors>
  <virtualDestinationInterceptor>
    <virtualDestinations>
      <compositeTopic name="orders">
        <forwardTo>
          <queue physicalName="orders.consumer1" />
          <queue physicalName="orders.consumer2" />
        </forwardTo>
      </compositeTopic>
    </virtualDestinations>
  </virtualDestinationInterceptor>
</destinationInterceptors>

This way when your subscriber eventually connects to its own queue, it drains the messages that were fed into it.

A word of caution, make sure that your memory limits are large enough to deal with the messages stored in these queues, or your broker will appear to hang (a broker function called producer flow control).

I see that you are a new user, so if this answers your question, please tick it.

Jakub Korab
  • 4,974
  • 2
  • 24
  • 34
  • Thx for your answer. In what case would we use pub/durable sub instead of virtual topic? My impression sofar virtual topic seems overall a better pub/sub approach only difference is backed by queue? – user1500049 Jul 11 '12 at 18:15
  • In practice, I always favour virtual topics. The only use cases I can think of that I might consider durable topics for, like web clients connecting to a broker, are almost always better served by retroactive consumers. Virtual topics are easier to think about, can be inspected via JMX, can be connection pooled, work correctly in networks of brokers and have destination policies (like message expiry, memory limits and DLQs) set on them. In short they're pretty much better in in every way. Don't forget to vote up if it helps! – Jakub Korab Jul 12 '12 at 08:21
0

you could look into using a durable queue (as opposed to a topic) and use queue browsers (subscribers) to receive messages. The onus on tracking sequence numbers is then on the subscriber side (not sure if that is doable in your case). Queue browsers do not delete messages from the durable queue. You either have to use messages with a time to live or perhaps use a regular queue subscriber after certain time periods to flush out the old messages.

Queue browsers with durable queues are less taxing on the server - but you're pushing more load on the subscribers.

Hope it helps.

ali haider
  • 19,175
  • 17
  • 80
  • 149