On Wed, Apr 11, 2018, 6:09 AM pragmaticjdev <amits...@gmail.com> wrote:
> We plan to use activemq to build a replicated cache in our distributed > system > consisting of multiple java applications. In this deployment, an update to > any of the objects being cached in the jvm memory of the app server acts as > a producer which pushes the pojo to the jms topic. All other app servers > subscribe to it and update the object that is cached by them. Here's a > quick > deployment screenshot with 2 app servers. In production we would have a > maximum of 5-7 such app servers. > > <http://activemq.2283324.n4.nabble.com/file/t378744/ActiveMQ_Oracle.png> > Have you considered using an actual standalone caching product such as Redis or MemCache as your cache rather than trying to create your own synchronized distributed in-memory cache? It seems like that would simplify your task significantly and reduce the risk of bugs and the need for troubleshooting. Reusing an existing product is typically better than re-inventing the wheel... I would like to get suggestions on below queries > 1. Given this is a real time use case (caching) we would want any > updates > to be replicated to all other app servers as soon as possible. What broker > configurations should we consider to make sure that the messages are > delivered in real time in all possible flows? > The default settings should be fine. 2. Would it be good to maintain a continuous connection with the > activemq > server on each app server in order to invalidate the cache in case the app > server fails to connect to activemq? If so, how could it be implemented? > If you use the TCP transport, it will stay connected continuously, and then disconnect if the broker goes down. If that happens, I believe an exception will be thrown the next time your code polls for new messages. 3. How do we handle failure scenarios when the producer fails to > push an > object to the topic (in which case we might have to rollback the database > transaction) or the consumer fails to receive the java object? > Is the work that leads to the message being published done in response to the consumption of a JMS message? If so, you can use an XA transaction to roll back your database commit if the send fails. But if you're not consuming a message at the time, I'm not sure that the built-in XA transactions are available to you. But I'm not an expert on transactions in a JMS context, so I could be mistaken about that. But you'd have to add special logic to remove the cache entry on transaction rollback. Again, I'd use a standalone cache for this rather than creating your own, if at all possible. Tim >
