Mailing-List: contact user-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Commons Users List" <user@commons.apache.org>
Received-SPF: pass (nike.apache.org: local policy)
Date: Wed, 16 Apr 2014 22:14:56 +0200 (CEST)
From: tendaf@free.fr
To: Commons Users List <user@commons.apache.org>
Message-ID: 
 <353081799.839007278.1397679296979.JavaMail.root@zimbra23-e3.priv.proxad.net>
In-Reply-To: 
 <1627100473.838878997.1397675394920.JavaMail.root@zimbra23-e3.priv.proxad.net>
Subject: RE: SCXML2 Serialization
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit

Thanks for your reply Ate.

I want to serialize/deserialize a SCXML 'session' for this use case :

Into a transactional server, a request is processed by a thread. An ID is retrieved from the message, with this ID the server loads a context (from a redis store) and instantiates a new 'Executor' with it's associated SCXML file and saved instance. 

I'll use invokers to call external functions or new a SCXML 'processor', I don't expect them to still be running after the state machine stabilized.

You said : "But then you should not set the statemachine again (after attachInstance) as that will re-initialize the SCInstance itself"
so I don't have to  do this "executor.setStateMachine(scxml);"because  scxml is serialized with the scInstance. But if I need to register a listener (addListener) or if I have custom actions, are they serialized too?

In the example I do 'setInitialState(executor, "paused");' because the call to go resets the state and I know that 'paused' is the last state. Of course  I want to 'return' in the same state I left off. Without a call of the  go function, the state machine seems to be frozen.


Thanks,

Regards
Francis.


--------------


Hi Francis,

There are a few things not right or needed in your approach below.
I've provided comments inline.


On 16-04-14 15:07, tendaf@free.fr wrote:
Hi all,

I would like to know the best practice to serialize/deserialize SCXML fsm.

I do this during the creation of the SCXML executor, scInstace is the serialized context:

             List<CustomAction> customActions = new ArrayList<CustomAction>();
             CustomAction ca =
                     new CustomAction("http://my.custom-actions.domain/CUSTOM1",
                             "hello", Hello.class);
             customActions.add(ca);

             JexlEvaluator evaluator = new JexlEvaluator();

             try {
                 scxml = SCXMLReader.read(StopWatch.class.getClassLoader().

             } catch (Exception e) {
                 e.printStackTrace();
                 throw e;
             }


             executor = null;
             try {
                 executor = new SCXMLExecutor(evaluator, null, new SimpleErrorReporter());

While you can recreate SCXMLExecutor each time, this is not the intended usage.
The SCXMLExecutor holds the external event queue. If you are using Invokers, and you *do* in your example, then these might still be (kept) 'running' while the state machine itself is currently stabilized. So after a return from go() or triggerEvent(). And these invokers might send back events into the external queue for further processing. So then you should keep hold of the SCXMLExecutor instance, across serialization/deserialization of the SCInstance.
If you don't use Invokers, or don't expect them to still be running after the state machine stabilized (which might be the case in your example?) then I guess recreating the SCXMLExecutor is fine. But then you should not set the statemachine again (after attachIstance) as that will re-initialize the SCInstance itself. Same goes for calling go() again or otherwise re-initializing the current state. What would be the point of serializing in that case anyway?
Note also, the statemachine is automatically serialized together with the SCInstance, so you actually don't need to set it again.


                 if (scInstance != null) {
                     // serialized context use it
                     executor.attachInstance(scInstance);
                     executor.registerInvokerClass("x-test", DummyInvoker.class);
                     executor.setStateMachine(scxml);
this shouldn't be done as it will re-initialize the SCInstance state
                     executor.go();
this does the same, so definitely shouldn't be done either, because this way there is no 'state' retained from what you serialized before
                     setInitialState(executor, "paused");
same goes for this: if you re-attach the instance, I assume you would want to 'return' in the same state you left off, right?


                 } else {
                     // new context
                     Context rootContext = new JexlContext();
                     rootContext.set("var1", "value1");
                     executor.registerInvokerClass("x-test", DummyInvoker.class);
                     executor.setStateMachine(scxml);
                     executor.setRootContext(rootContext);
                     executor.go();
This initialization part is fine

                 }

             } catch (ModelException me) {
                 // Executor initialization failed, because the
                 // state machine specified has inconsistencies
                 me.printStackTrace();
             }

I serialize executor.detachInstance(). It's seem to work, but is it the right way to restart a SCXML 'session' ?
See comments above. You're almost good but especially need to think about the Invoker use-cases and if that might require you to keep hold of the SCXMLExecutor instance.

Regards, Ate

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@commons.apache.org
For additional commands, e-mail: user-help@commons.apache.org