Re: Using ActiveMQ For Distributed Replicated Cache
On Mon, May 7, 2018 at 8:10 AM, pragmaticjdev <amits.84@xxxxxxxxx> wrote:
> I think there is some misunderstanding that I created. We don't plan to use
> activemq to populate the cache. We build the cache on cache misses. Here's
> how the overall flow looks like. Note there are multiple jvm's involved, I
> have just pictured one for simplicity.
Do you truly mean that you don't plan to use ActiveMQ to build the cache?
Or are you just saying that you attempt to build the cache via ActiveMQ
because it's more efficient but that guaranteed delivery isn't required,
because if ActiveMQ misses a message, the cache-miss logic will fill in
whatever gaps might occur? If you're truly not using ActiveMQ to build the
cache, what are you using it for?
> I didn't completely follow your response to the durability question.
> Probably this diagram helps me to explain how the cache behaves in read and
> write operations. Please let me know if you still see problems with
> @JmsListener(DefaultMessageListenerContainer) and non-durabilty.
All I meant was that for a non-durable topic subscription, the Spring
JmsTemplate code will disconnect between messages, which results in the
subscription being removed and then re-created the next time the code
connects. If a message is sent when the subscription doesn't exist, the
message will not be delivered when the consumer next creates the
connection, because the subscription did not exist at the time the message
was sent. This is standard topic behavior, but users often don't expect the
JmsTemplate to remove the subscription between calls so it trips up some
users. If you can accept a non-trivial percentage of your updates not
making it into the cache and being filled via cache misses that query the
database, this isn't a problem, but since you've described updating objects
(which will return a stale object from the cache instead of resulting in a
cache miss) you might not be able to live with this behavior. If you can't,
you'll want to use a durable subscription, and you'll need to ensure that
if your consumer disappears for a significant amount of time, your broker
is configured to discard the messages or the subscription (or both).