[rules-users] High availability with a drools cluster

[Chakravarthi Muppalla]

Hello All,



We are planning to user drools for our event driven business rules
execution. I’m designing this around the features available in Expert
engine, Fusion, Guvnor.



An overview of the system will look like this.



1.)    1.) We will have N application nodes with an embedded drools engine.
These nodes will be subscribed to the JMS(mostly ActiveMQ) and a clustered
cache.

2.)    2.) All the customer activities will be pushed onto the JMS. One of
these N nodes will get the customer activity event. This node will update
the cache (customer related data cache) with this activity.

3.)   3.)  As all the nodes are connected to the cache, each one of them
will get a call back about the cache entry.

4.)    4.) If this is the first activity of the customer, One of the nodes
will act as a master to pick up this and insert this into the stateful
session’s working memory.

5.)    5.) Any further cache call backs related to this user will be sent
to this node.



In case one of the nodes go down, I want one of the other nodes to resume
the execution of the affected customers.

To translate this into drools, I want one of the nodes to pick up the
session of the failed node.  As this is not available out of the box, I’m
looking for possible approaches.



I’m thinking of writing the working memory contents to a middle tier
cache(possibly radis) backed by persistence(mysql). This cache will write
the data to the persistence either at certain intervals or on certain
events.



I’m certain that other nodes can be notified, if one of the nodes go down.
So the question is, about the possibility to write/read the session to/from
a cache, pick up with session and seamlessly resume the execution. Are
there any practical approaches to store the working memory in a cache
instead of just the VM memory?

-- 
Cheers!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/rules-users/attachments/20140303/693284ea/attachment.html