Actually the subscription recovery policy does not work for my case, because it only allows to send to the new client a message previously sent to the topic, not a different one.
2016-09-02 15:20 GMT+02:00 Matt Pavlovich <mattr...@gmail.com>: > +1 the subscription recovery policy should do it. Might makes sense to > separate the destinations as well.. one for boot strap and another for > updates. > > > > On 9/1/16 2:19 PM, Julien Nicoulaud wrote: > >> I realize using retroactive consumers with a >> custom SubscriptionRecoveryPolicy might be just what I need. >> >> 2016-09-01 21:06 GMT+02:00 Julien Nicoulaud <julien.nicoul...@gmail.com>: >> >> Hi, >>> >>> I'm trying to implement the following simple pattern using ActiveMQ: >>> - my server maintains a "state" >>> - my clients connect to the server, get a snapshot of the state and >>> suscribe to updates of the state >>> >>> So I need the "state snapshot + subscription" step to be atomic for each >>> client connecting to the updates topic. >>> >>> So far the only solution I can think of is: >>> - put an absolute sequence number on update messages >>> - use separate temporary queues for state snapshot requests (like >>> described here: http://activemq.apache.org/how-should-i-implement- >>> request-response-with-jms.html) >>> - each state snapshot is tagged with the sequence number of the >>> corresponding update >>> - when a client connects, it suscribes first to the updates topic, then >>> requests the snapshot state, and just discards updates that are older >>> than >>> the snapshot state >>> >>> I feel there might be a smarter solution, as strict ordering is built in >>> the framework ? Or maybe using advisory messages ? >>> >>> Thanks, >>> Julien >>> >>> >
