Durability / Restored Session Appears Frozen

[Pranav Ram]

Hi All,

In Issue #198 (https://github.com/cerner/clara-rules/issues/198) it's mentioned that one of the goals for the durability is A restored session state should be ready-to-go. It should be able to have new facts inserted and the fire-rules called again as if we are in the same process as the original session was in.

I'm currently prototyping an example where I serialize the session and after deserializing, try to retract facts to simulate what-if scenarios. I'm unable to insert or retract facts after deserialization and the session appear frozen. I've tried this with both a full session serialized as well as the working memory and rulebase serialization separately.

Is this the intended behaviour? I'm also persisting and loading facts using nippy.

Without durability, the use case works fine and I can manipulate the session.

I'm using [com.cerner/clara-rules "0.21.1"] currently.

Happy to share any other info. Thank you!

[ethan.e....@gmail.com]

Hello, 

Does it "freeze" while deserialization is occurring, or does it eventually deserialize the rulebase/session?
Additionally, do you have a small snippet that I can try and use to reproduce this?

Thanks, 
Ethan

[Pranav Ram]

Hi Ethan,

It actually does deserialize the session completely and I'm able to inspect, explain-activations, etc on the deserialized session. However, I'm unable to modify the session such as insert or retract facts after it is restored from the file system. Whatever state the deserialized session was in remains through all these insertions and retractions.

I've tried to reproduce a working example in one file (attached)

Please let me know if you need anything else. You'll need to create a "_data" folder in the root for it to persist the session artifacts.

Thank you for the help!

[ethan.e....@gmail.com]

Hey  Pranav,

Thanks for the example, I was able to get it running and replicate the behavior you mentioned(Insert/Retracts not behaving as intended).

I believe the root of the issue you are experiencing is a little "gotcha" with the implementation of durability, specifically when using fact-type-fns.

In your  example your "pre-serde" session uses:
        (mk-session name-space rules :fact-type-fn FACT-TYPE)

However, on deserialization: 
        (d/deserialize-session-state (df/create-session-serializer is)
             wm-serializer)

The fact-type-fn is not being provided via the opts param:
   https://github.com/cerner/clara-rules/blob/e86dcd4f0224d966c1bd82043e79cf59c96136bf/src/main/clojure/clara/rules/durability.clj#L701 

I believe that by updating the line mentioned above to something like:
    (d/deserialize-session-state (df/create-session-serializer is)
       wm-serializer
       {:fact-type-fn FACT-TYPE})

should sort out the undesired behavior. Please let me know, if it does or doesn't.

For context as to why this "gotcha" exists:
As clara supports arbitrary functions for fact-type-fn, during serde we are unable to persist the function across the serialization boundary and thus require users to provide it on the other side.

Hope this helps,
Ethan

[Pranav Ram]

Fantastic, that solved it, Ethan. Thank you for the help!

I'd like to submit a PR to the clara site (https://github.com/cerner/clara-site) in the durability section mentioning this for other potential users. I assume this is the right place?

Pranav

[ethan.e....@gmail.com]

Yes, you have the correct repo there.
Please feel free to toss up a PR to add this to the documentation, we always appreciate contributions.

Ethan