Rules dynamic/hot deployment

[BinitaBharati]

Hi.

I went through the features of clara-rules. Could not find hot deployment listed among it. I am looking for something similar to : http://docs.jboss.org/drools/release/5.2.0.Final/drools-guvnor-docs/html/ch09.html. This feature periodically scans a particular directory for any changes (add/update/delete) to Jboss drool files, and loads the changes into memory.

Reason I am asking this is that in production , it may not be always possible to restart the rules JVM to accommodate changes.

Thanks

[rbrush]

There isn't (yet) tooling around hot deployment, but there are a couple ways it can be accomplished with Clara. Two options come to mind:

Clojure itself provides some ability to dynamically re-load namespaces -- and since Clara is just Clojure code, it would work for Clara as well. You can checkout clojure.core/remove-ns to remove a namespace and clojure.core/load-file to dynamically load a file. This would apply to files in which rules are stored.

The second option would be write rules to EDN and store them externally (a file, a database, or any handy data store.) There is an example in the unit tests that show reading rules from an EDN structure in action. There currently isn't code to write to an EDN file from Clara, but that could be accomplished by simply calling (load-rules 'my-rules), which returns a sequence of rule structures, and those could be written to EDN.

The EDN structure could then be loaded and used as the rule source at any time.

[rbrush]

One more comment: I'd be happy to add or accept contributions for more direct support of dynamically re-loading rules. It would probably just come in the form of one of the techniques listed above wrapped in a convenience API. Until then the above model should work.

[eslick]

Reloading rules implies starting a new session, correct? If so, doesn't that dump working memory? If working memory is maintaining interesting state is there any way to make sure it's reconstructed where applicable to the new rules?

[rbrush]

Yes, reloading rules does mean starting a new session, which would dump the working memory. I think the best way to retain state when loading new rules might be to simple plug into the change log idea being discussed in #16, and reproduce the state by replaying changes.

This doesn't necessarily mean every fact inserted and rule executed needs to be replayed. For instance, we could omit retracted facts and include only the outcome of accumulators (rather than all of the facts that contributed to them).

Obviously a lot of open questions here. Of course, the simplest (although most expensive) solution would be to keep the sequence of incoming data independent of the rule session, and simply re-run it when a new session is created. This might be workable in some cases.

[eslick]

I'll have the ability to reconstruct most of my facts from the underlying database and hold off real time events until the session is back up and running but I think restoring the state of accumulators is important. I'd be fine with a mostly offline solution where you create the new session with the new rules, hold off on injesting new events, snapshot the old, update the new from the snapshot where there is correspondence, then pick up the external event stream from there. So logs and snapshots are the hot items...

[ghost]

Hi Ryan,

I want to verify that with all the changes since the OP posted this if we can still dynamically load rules. I want to inject rules from the backend in a cljs client. Yeah, another twisted use :) Maybe not in context as dynamic as the OP but along the same line.

I'll be reusing Clara for the same customer where I implemented Clara in Dec. 2014 but will extend its use in the business backbone.

I set aside some time to work on Clara itself and why not try to fix some of the open issues. Thank you,

Luc

[mrrodriguez]

From what I read here the topic sort of is leaning towards durability of the rule base + working memory. This is something I'm actively working on with https://github.com/rbrush/clara-rules/issues/198. Just heads up if that's what you're looking at.

The idea would be to persist the rule base and the state of working memory. Then be able to read it back later. My emphasis is currently on not needing to replay changes in the interest of time but rather persist the memory state a bit more directly than that.

[ghost]

Hi,

my immediate interest is to serve rules from a server to client browsers, avoiding the round trip time asking the server to validate the state of some complicated GUI data entry on the client side. And I do not want the rules to be frozen in the client code. The server will be able to reload them dynamically, the clients should also obtain them in the same way.

Session durability presently is not in the scope yet. It might be later but it' s like Hygrade sausages, you sell more of them because more people eat them and because more people are buying them because ....

I'll see how far the customer wants to go with this along the way. If I have a need to preserve session states from clients I will certainly look at #198 and your work.

Presenty some people (other suppliers) over there have a decent level of disbelief that business rules can be centralized and served to remote clients 😁 For them, this kind of stuff is implemented in code and you can' t send code on the wire.

Since I like challenges, I will prove them wrong 😂, at least I have a reasonnable expectation that I can get there. Of course they know little about Lisp and Clojure, I do have a big poker hand and they do not realize that yet.

(circus song) ... drum rolling.... Tadaaaa !

I might even need to get clara rules to work on the CLR... you never know. Be seeing you (#6 fan)

[rbrush]

Hey Luc,

None of the changes have impacted the ability to dynamically generate or load rulesets. Dynamically generating ClojureScript rules and sharing them between client and server (if I recall earlier discussions correctly) isn't something we've done much of so I can't vouch that particular flow is well tested...but at least we haven't taken any steps backwards there.

[ghost]

Great, I have a few ideas and with the addition of eval in ClojureScript... I'll keep you posted.

A+ Luc