activemq-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Justin Bertram <jbert...@apache.org>
Subject Re: Using ActiveMQ For Distributed Replicated Cache
Date Tue, 17 Apr 2018 16:40:34 GMT
I agree with Tim about using an existing cache implementation. It seems
like a lot of work to re-invent the wheel here. If you're looking for an
open-source, Java-based cache implementation which uses the ASL 2.0 (e.g.
similar to Apache ActiveMQ) checkout in Infinispan [1].


Justin

[1] http://infinispan.org/

On Tue, Apr 17, 2018 at 8:34 AM, Tim Bain <tbain@alumni.duke.edu> wrote:

> On Wed, Apr 11, 2018, 6:09 AM pragmaticjdev <amits.84@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
>
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message