How to create/preconfigure durable subscriber(s) in activemq.xml so that these subscriptions are ready upon ActiveMQ starts up?

Question

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.

Answer 1

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.

Answer 2

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.