On Mon, May 7, 2018 at 8:10 AM, pragmaticjdev <amits...@gmail.com> 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. > > <http://activemq.2283324.n4.nabble.com/file/t378744/ActiveMQ_Oracle.png> > > Thanks. > 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). Tim
