| <div class="wiki-content maincontent"><h2>Background</h2> |
| |
| <p>A retroactive consumer is just a regular NMS 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 <link><page ri:content-title="Subscription Recovery Policy" ri:space-key="ACTIVEMQ"></page></link> for more detail.</p> |
| |
| <h3>Example</h3> |
| |
| <p>You mark a Consumer as being retroactive as follows:</p> |
| |
| <structured-macro ac:macro-id="ba59700d-4562-492c-a54b-67abdf21067a" ac:name="code" ac:schema-version="1"><parameter ac:name="">java</parameter><plain-text-body> |
| var topic = session.GetTopic("TEST.Topic?consumer.retroactive=true"); |
| var consumer = session.CreateConsumer(topic); |
| </plain-text-body></structured-macro> |
| |
| <h2>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> |
| |
