[rules-users] High availability with a drools cluster

[Chakravarthi Muppalla]

Thank you Mark.

I'm planning to marshal the knowledge session at regular intervals. When
the server is restarted, it can load the session and reinsert the events
occurred during the downtime.

As an alternative to this approach, I'm looking at creating a knowledge
session per user. This way we'll be creating many knowledge sessions, But I
believe persisting them will be quick. Are there any side effects to this
approach?

--
Cheers!



On Tue, Mar 4, 2014 at 4:52 AM, Mark Proctor <mproctor at codehaus.org> wrote:

> Edson will be working on building a clustered HA execution server during
> the spring and summer period. No details yet, he’s just starting this now.
>
> We’ll be taking a slightly different approach. Master will run and produce
> a incremental journal of non-reproducable state changes; such as the state
> of the agenda. We’ll replicate that journal log, along with user entity
> state changes to the slaves for replay.
>
> 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?
>
> You can marshal a session to a byte[] and persist that, the down side is
> serialises the entire session every time. So it can be quite heavy, which
> is why are trying to work on a incremental journal approach instead.
>
>
> Mark
> On 3 Mar 2014, at 07:46, Chakravarthi Muppalla <chakri143 at gmail.com>
> wrote:
>
> 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!
>  _______________________________________________
> rules-users mailing list
> rules-users at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users
>
>
>
> _______________________________________________
> rules-users mailing list
> rules-users at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users
>



-- 
Thanks & Regards,
Chakravarthi.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/rules-users/attachments/20140305/2c45377d/attachment.html