Message groups just got a bit better

As the first sentence of the message groups documentation page says: message groups rock. One of the problem with them, however, was an inappropriate behavior in case you’re adding your consumers for the messages already stored in the broker (with appropriate message group parameters set). This also causes that message groups are not honored in master slave environment, because when master goes down you can end up with your producer sending some messages to the slave before your consumers subscribe.

In 5.3 this problem is solved, but there is one catch worth mentioning. If you connect your consumers and start dispatching immediately, you will probably end up with your first consumers acquiring all messages groups. There are a couple of mechanisms you can use to avoid this behavior. First, you can add a small pause between first consumer subscribed and actual message dispatch starts. You can do that with the timeBeforeDispatchStarts destination policy option, which defines the number of milliseconds the broker will wait before dispatch starts.

        <destinationPolicy>
            <policyMap>
                <policyEntries>
                    <policyEntry queue=">" timeBeforeDispatchStarts="200"/>
                </policyEntries>
            </policyMap>
        </destinationPolicy>

If you know exact number of consumers, you can also do something like this

        <destinationPolicy>
            <policyMap>
                <policyEntries>
                    <policyEntry queue=">" consumersBeforeDispatchStarts="2" timeBeforeDispatchStarts="2000"/>
                </policyEntries>
            </policyMap>
        </destinationPolicy>

This configuration instructs the broker to wait for two consumers to subscribe (or 2 seconds) before it starts dispatching. If you omit the timeBeforeDispatchStarts parameter, the default timeout of 1 sec will be used.