activemq-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Julien Nicoulaud <julien.nicoul...@gmail.com>
Subject Re: Publish/suscribe pattern question
Date Fri, 02 Sep 2016 15:36:08 GMT
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 <mattrpav@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.nicoulaud@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
>>>
>>>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message