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 <jlindw...@yahoo.com> 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: > http://activemq.2283324.n4.nabble.com/Depending-on-TransportListener-for-cache-consistency-tp4700535.html > Sent from the ActiveMQ - User mailing list archive at Nabble.com. >
