activemq-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Shannon <>
Subject Re: Depending on TransportListener for cache consistency
Date Sat, 08 Aug 2015 22:42:26 GMT
I don't know the exactly details of your use case but this seems reasonable
to me as long as you account for the fact that messages could still be lost
or not received in a timely matter even if there isn't a broker restart or
lost connection.  An example where a message could be lost is if the topic
is backed up and the client is doing an asynchronous send. Another example
would be a back log on the topic that causes producer flow control to kick
so that messages could be received slowly or could expire if there a TTL
set. One thing you could do to account for these kinds of things is to just
set a max time on elements in your cache before they are evicted
automatically to make sure nothing is stale in case the flow breaks down.

On Thu, Aug 6, 2015 at 4:37 PM, jlindwall <> wrote:

> We use a JMS topic to coordinate distributed caches.  We have a topic
> called
> "caching" using non-persistent messages.  The subscribers are (of course)
> non-durable.
> A message in the topic means "clear your cache for the specified datatype
> (and id)".  Multiple webapps subscribe to this topic (and also publish).
> When a webapp makes a change to a piece of data, it publishes a message to
> the topic to tell the other webapps to clear their cache for that
> particular
> piece of data.  In this way we enforce cache consistency.
> We are using a "Shared filesystem Master/Slave" using kahadb.  If the
> master
> fails, then the clients are notified via the ActiveMQ TransportListener
> mechanism.  When the connection is determined to be lost (via the
> TransportListener), each client clears ALL ENTRIES in it's cache.  When the
> connection is reestablished, the cache will be refilled naturally.  This
> keeps the cache consistent in the face of a broker failure.
> We contemplated using persistent messaging and durable subscribers for this
> scheme, to make sure no message were lost. I am thinking that we do not
> need
> to pay the price for persistence and instead use the above scheme based on
> TransportListener.
> Can you see any faults in this approach?
> Thanks!
> --
> View this message in context:
> Sent from the ActiveMQ - User mailing list archive at

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