<div class="wiki-content maincontent"><h2 id="RetroactiveConsumer-Background">Background</h2>

<p>A retroactive consumer is just a regular JMS <strong>Topic</strong> consumer who indicates that at the start of a subscription every attempt should be used to go back in time and send any old messages (or the last message sent on that topic) that the consumer may have missed.</p>

<p>See the <a shape="rect" href="subscription-recovery-policy.xml">Subscription Recovery Policy</a> for more detail.</p>

<h3 id="RetroactiveConsumer-Example">Example</h3>

<p>You mark a Consumer as being retroactive as follows:</p>

<div class="code panel pdl" style="border-width: 1px;"><div class="codeContent panelContent pdl">
<script class="brush: java; gutter: false; theme: Default" type="syntaxhighlighter"><![CDATA[
topic = new ActiveMQTopic(&quot;TEST.Topic?consumer.retroactive=true&quot;);
consumer = session.createConsumer(topic);
]]></script>
</div></div>

<h2 id="RetroactiveConsumer-Limitations">Limitations</h2>

<p>Retroactive consumer will not consistently work when used across a network of brokers.</p>

<p>In the case of topics, when we connect broker A to broker B, broker B will send broker A all the subscriptions that it has received. Since Broker A replicates messages to each subscription, and we want to avoid receiving duplicates at broker B, we can't send broker A more than 1 subscription for the same topic. So our network bridges keep track of the subscriptions sent across and only send the first subscription to a topic. Subsequent subscriptions increment the reference count of the subscription, but the subscription is not actually sent.</p>

<p>This in essence is the problem. If the first subscription to a topic is not retroactive, it is sent B to A, and the B broker will not get the retroactive messages. Then subsequent subscriptions could be (retroactive), but it will not cause retroactive message to sent from broker A to broker B since the subsequent subscription will not be sent to broker A.</p></div>