On Wed, May 2, 2018, 12:02 AM pragmaticjdev <amits...@gmail.com> wrote:
> Thanks Tim for your valuable comments. > > 1. > > > so you're using message-driven code rather than managing the connection > > yourself. In that case you'd want to do the following to handle the > error > > (by clearing the cache): > > > https://stackoverflow.com/questions/40654586/spring-jms-set-errorhandler-for-jmslistener-annotated-method > > On your suggestion of registering an ErrorHandler, I wanted to confirm my > understand - Does the subscriber underneath continuously poll activemq and > a > failure in doing so gets the ErrorHandler implementation invoked? > That's my understanding, though I'm not an expert on the Spring code. If you have more detailed questions about the Spring JMS library specifically, you might want to either take a look at its source code or post a question on the Spring forum or on StackOverflow. 2. > > > Tim Bain wrote > > @JmsListener is typically used with a > > DefaultMessageListenerContainer, which interacts poorly with topics if > the > > subscription is non-durable > > Are you suggesting we enable durability? Is there an alternative? I ask > because theoretically we don't need durability of the messages. If the > subscriber is down when the message is published to the queue, it is > perfectly ok as the cache is designed to build as requests are received. We > go to the RDBMS store on a cache miss and the subsequent requests then are > handled by the cache. > A non-durable subscription may increase the likelihood of those cache misses, but as long as that's acceptable, it's probably better than using a durable subscription where you would have to configure a mechanism for dropping the subscription (and the built-up backlog of unconsumed messages) after some timeout. Out of curiosity, why use ActiveMQ to populate your cache at all, rather than just populating it on each cache miss (which is simpler)? I'm not saying there aren't valid reasons for doing what you're proposing, but I'm curious what your reasons are for deciding that this is worth the extra complication. Tim >
