Persisting / restoring interpreter state

[sbidoul]

Hi,

I'm looking for a mechanism to persist / restore interpreter state.

My current approach is to persist Interpreter._configuration to database. To restore it I instantiate Interpreter wit a restored initial context, then set _configuration obtained from database. Of course, persisting _memory would be needed too if using history states.

Obviously, I'm using an non public API by accessing/restoring Interpreter._configuration directly.

This worked well until 1.3. It breaks with sismic 1.4 because of the TimedContextEvaluator which has it's own copy of the states _configuration. Since I don't restore it, it starts with an empty _configuration and it breaks when exiting state at

sismic/sismic/code/context.py

Line 72 in b2f0708

self._configuration.remove(event.state)

.

Pickle is not an option for us for many reasons, mostly because it does not lend itself to data migration (if we evolve the state machine, it is possible to update _configuration during data migration, while updating a pickle is not practical).

So I'd like to discuss if pausing a state machine by persisting it to database makes sense as a use case for Sismic? If yes, what could be a stable API for persisting/restoring interpreter state?

[AlexandreDecan]

Hello,

Saving and loading statecharts at runtime is not part of what Sismic offers at the moment. I do understand how interesting this can be, but providing official support for this feature will require a lot of effort, especially if you want to be complete in this support (property statecharts, listeners, code evaluator, context providers, etc.).

Recent changes made to "isolate" some code evaluator features have indeed made workarounds more complex to implement (on the contrary, they greatly facilitate support for other languages or other code evaluator features).

A possible solution is to implement a "load/save protocol" for each object involved in the execution of the statechart. This protocol would consist in collecting, for each "component" of the execution, the variables defining its state and returning them (probably based on lists and dictionaries, in order to facilitate its export to formats such as json or yaml for example). If this is possible for objects such as the interpreter or code evaluator, it is more delicate for listeners who can be attached to the interpreter at runtime (and this includes, unfortunately, the context providers).

In your case, a possible workaround would be to override the value of _configuration in the TimeContextProvider. This provider is stored in the _time_provider variable of a PythonEvaluator.

Another possibility if the statechart is not doing any kind of interaction with "external objects" is to "replay" the sequence of events that lead to its current state. This can be done by recording all the events that are sent (and the time at which they are sent), either manually (e.g. using the trace provided by helpers.log_trace) or by creating a new listener that will be attached (see Interpreter.attach) and will store the "event consumed" meta-events (and the current time) sent to the statechart being executed.

It should also be possible to subclass a PythonEvaluator and to remove/mock its context providers if their features are not required by your use cases, but I wouldn't recommend this approach ;)

[sbidoul]

Thanks a lot for the quick and detailed answer.

Replaying won't work because actions are typically not replayable (due to interactions with other statecharts or external systems or other database objects).

From my part I feel the main part of the load/save protocol is obviously states and memory. The context load/save protocol can be a noop and left to be provided by the user (a documented way to provide it is needed though). I need to learn more about the other context providers and listeners.

[AlexandreDecan]

The context providers are used by the code evaluator to help providing e.g. time-related predicates in the context that is exposed by the code evaluator. Previously, all these predicates were directly computed and executed by the code evaluator (making them not "portable" to other code evaluators).

The context providers are created by the code evaluator upon instanciation (usually, by the interpreter at creation time). These context providers are then attached to the interpreter so they are notified about what happens during execution (e.g. which are the states that are entered, exited, what is the current time, and so on). Due to this "attachment" process, not only their "internal memory" will have to be restored, but they also need to be attached to the interpreter as well (it's a kind of dependency injection). I don't see how we can circumvent this in the current implementation, unless we provide some additional parameters to the code evaluator to "disable" some context providers (so they won't trigger errors like the ones you got, but their predicates won't be available during execution :-/)

[sbidoul]

I was thinking about disabling the TimeContextProvider, but I notice it provides an important active predicate which I need (and that is somewhat unrelated to time at first glance).

The EventContextProvider seems to be less of an issue, because its state seems to be reset when the state machine stabilizes (which is when we persist it).

[AlexandreDecan]

I would say that if you're not afraid of digging into Sismic internals, the "easiest" way (the more straightforward one) is probably to manually override the content of _configuration in the TimeContextProvider that is associated to the code evaluator.

I don't see any easy way to quickly provide a load/save option for an interpreter right now, and I won't really have time to consider this during the next few weeks (probably not before mid February to be honest). Because of the modular nature of Sismic, many informations related to the execution are spread in different objects at runtime, making it difficult to provide such support (and even if we manage to have a load/save feature, it won't be easy to allow statechart transformations in between).

To support both use cases (load/save and changing the active configuration), I think I'll need to remove the context providers and find another way to "isolate" them so they can be reused in other code evaluators as well. Or maybe directly support them in an Interpreter, so that the whole current state of the execution is in a single place.

[sbidoul]

Short term the easiest is to pin my dependency at 1.3 :) No urgency at all, thanks for all the feedback. Happy to discuss further later.

[AlexandreDecan]

I quickly tried to move the internals required by time and event-related predicates to the Interpreter instead of context providers. It was quite easy to make the current PythonEvaluator work with this approach, and tests are not failing (at least on my computer, I'm still waiting for Travis for an in-depth testing).

Could you please have a look at the corresponding branch?
https://github.com/AlexandreDecan/sismic/compare/no-context-provider?expand=1

I think it preserves the behaviour you had with 1.3. Basically, I added three new private attributes to an Interpreter, namely _entry_time, _idle_time and _sent_events. The two first ones store the time when a state is entered and when a state has one of its transition that is triggered. The last one captures all the events that are sent during the current macrostep.

To "freeze" an interpreter, assuming you do not rely on contracts (or at least, not using the __old__ variable that is still in PythonEvaluator), it should be sufficient to store the value of _memory (if history states are used), _statechart (or to provide a similar one upon instanciation), _configuration (it isn't duplicated anymore), clock, _entry_time and _idle_time (to support after and idle during code evaluation), both event queues (_internal_queue and _external_queue) and the _context of _evaluator (that can be provided as an initial context of the Interpreter). I hope I haven't forgotten anything ;-)

In case you want to change the statechart (adding or removing states, changing their names, etc.), you need to update the configuration AND the memory (if history states are used) AND entry/after_time (if you rely on after or idle at some point).

[sbidoul]

@AlexandreDecan that was quick. My tests pass with the no-context-provider branch.

[AlexandreDecan]

The changes are included in Sismic 1.4.1. It will be available on PyPI in a few minutes.

[sbidoul]

@AlexandreDecan thanks a bunch!

Regarding a future save/load API for the interpreter configuration, I have the same inventory as yours.

Here are my thoughts on a potential future load/save API:

• save_configuration/load_configuration methods on Interpreter
• save_configuration would export a dictionary with documented keys configuration, memory, clock, entry_time, idle_time, that's easy to serialize as json or yaml
• IMO providing statechart and context at Interpreter instantiation is fine
• regarding the queues, I'm not too sure: my intuition is that save_configuration happen in practice when queues have been consumed completely