[SCXML] Synchronizing state matchines

[Cedric NICOLAS]

Hi everybody,

We are starting to use SCXML and Java implementation to set up state
machines that represent a coordinated network of mobile devices. We are
using a master state machine that acts as a coordinator and many identical
state machines that represent the mobile devices coordinated by the master
one.

The master SM changes of states according to different states of the devices
state machines, with some complex coordination conditions.

I¹ve two questions related to this :

* as our project will integrate an increasing and important number of
states, transitions and events for the device states machines, we would like
to avoid at maximum to use Java for describing the states and event flow,
but do that in SCXML. Reason is maintainability and readability of code. How
to trigger easily events to device states machines from the master state
machine or the opposite ? More precisely, how to reference in the master
state machine the associated devices state machines ? Each device state
machine has a different SCXMLExecutor instance and context , as they of
course might be in different states at one specific moment. But how  to
trigger events in XML file  from one state machine to other states machines
like (master->device, device->master, device->device events)  ? It seems
that the target field is to be used for this, but how to reference other
state machines from the XML file ? Of course we know how to do this in Java
code, but triggering events as well as from Java code and from XML code,
increase a lot the tuning of the whole system, as it¹s becoming confusing to
understand who triggers what and when, when state machine becomes complex.
* we may have a quite important number of device state machines running
simultaneously (thousands) coordinated by several independent master state
machines. Has anyone have experience of performance bottlenecks of such an
architecture, as we will have to react in quite short response time to the
device events ? In other words, if we load in memory thousands of state
machines (typical life time of one device state machine will be between one
and two hours), will we face important memory consumptions problems ? A
solution based on data base persistent state machines, loaded on request
when we got an event, then updated in database and released from memory
wouldn¹t be better ?  (real time concurrent state machines at a given time
will be a much smaller number, as we¹ll get roughly ten to twenty events
from the devices during the lifetime.)

Thanks for your advises, as always that kind of questions in project start
time are key for future scalability

Cedric NICOLAS
Ville Fluide

[Rahul Akolkar]

On Mon, Jun 29, 2009 at 7:05 PM, Cedric
NICOLAS<cedric.nicolas@...> wrote:

> Hi everybody,
>
> We are starting to use SCXML and Java implementation to set up state
> machines that represent a coordinated network of mobile devices. We are
> using a master state machine that acts as a coordinator and many identical
> state machines that represent the mobile devices coordinated by the master
> one.
>
> The master SM changes of states according to different states of the devices
> state machines, with some complex coordination conditions.
>
> I¹ve two questions related to this :
>
> * as our project will integrate an increasing and important number of
> states, transitions and events for the device states machines, we would like
> to avoid at maximum to use Java for describing the states and event flow,
> but do that in SCXML. Reason is maintainability and readability of code. How
> to trigger easily events to device states machines from the master state
> machine or the opposite ? More precisely, how to reference in the master
> state machine the associated devices state machines ? Each device state
> machine has a different SCXMLExecutor instance and context , as they of
> course might be in different states at one specific moment. But how  to
> trigger events in XML file  from one state machine to other states machines
> like (master->device, device->master, device->device events)  ? It seems
> that the target field is to be used for this, but how to reference other
> state machines from the XML file ? Of course we know how to do this in Java
> code, but triggering events as well as from Java code and from XML code,
> increase a lot the tuning of the whole system, as it¹s becoming confusing to
> understand who triggers what and when, when state machine becomes complex.

<snip/>

Yup, the idea is to model these interaction patterns as SCXML actions
(standard or custom [1]) so that these become a little more
declarative, and more importantly, can be expressed in the SCXML
document itself rather than auxiliary procedural code. Some
brainstorming in terms of the scenario above:

 * The master state machine needs to be a well-known endpoint (could
be REST, webservice, any addressing means that make sense) for all the
mobile devices that want to coordinate. The master state machine
perhaps needs to be instantiated first, though with timeouts and
retries things can also be managed either way.

 * When a device's state machine comes up, one of the first things to
do would be to send a registration event to the master. The purpose of
this event would be to enable the master in addressing the device,
either directly or via a local proxy that gets injected as part of the
event payload -- again, the addressing scheme and registration
mechanism are completely application-specified, and very likely the
master state machine will hold some sort of device registry in its
(root) context [2]. The master may complete the handshake with an ack
before the device does anything else. Beyond that, events can flow
either way.

 * Now coming to the question of expressing all this in the various
SCXML document(s). Since you already know the recipe in Java code, we
just need to package it as a parameterized SCXML action. The SCXML
<send> standard action is designed for such communication (you can
always use your own custom action to further specialize any of this
processing, but lets see how this will work with <send> here). Lets
say the well-known endpoint for the master is the fictitious
"scheme://foo.bar/master", then all device state machines may boot
like so:

  <scxml ... initial="register">

    <state id="register">
      <onentry>
        <send target="scheme://foo.bar/master" targettype="x-mobile"
              event="device.register" namelist="myname myaddress"/>
        <!--
            'x-mobile' is a custom targettype, though x-* is generally
            discouraged scheme these days, you can use some such name.
            'myname' and 'myaddress' are variables in this context
            contain this state machine's info that the master can use.
            There could be more than two pieces of information that gets
            sent here ofcourse (whatever is needed).
        -->
      </onentry>
          <transition target="..."/>
    </state>

    <!-- The rest of the device state machine -->

  </scxml>

(you may need to single quotes literals depending on expression
language in use throughout these snippets, so
target="'scheme://foo.bar/master'" rather than
target="scheme://foo.bar/master" if needed)

The Java code that does the actual work now needs to be packaged as
part of the EventDispatcher [3] that gets registered with this
device's state machine.

In the master state machine, the above event may be captured by a
transition in a top level state like so:

  <scxml ... initial="master">

    <state id="master">

      <transition event="device.register">
        <my:register name="_eventdata.myname" address="_eventdata.myaddress"/>
        <!-- All the registration bits, including the ack may be handled
             by the above custom action, for example -->
          </transition>

      <!-- The master state machine -->
        </state>

  </scxml>

Likewise, the master state machine will have a similar EventDispatcher
that will allow it to send events to the devices.

  <send target="registry.device1" targettype="x-mobile"
        event="device.beep" namelist="beepduration"/>
  <!-- registry.device1 may return scheme://foo.bar/device1
       for instance -->

Device to device events then with some sharing of the device registry
that is currently with the master (update events could be multicast,
broadcast or anycast per design when devices come on and drop off).

> * we may have a quite important number of device state machines running
> simultaneously (thousands) coordinated by several independent master state
> machines. Has anyone have experience of performance bottlenecks of such an
> architecture, as we will have to react in quite short response time to the
> device events ? In other words, if we load in memory thousands of state
> machines (typical life time of one device state machine will be between one
> and two hours), will we face important memory consumptions problems ? A
> solution based on data base persistent state machines, loaded on request
> when we got an event, then updated in database and released from memory
> wouldn¹t be better ?  (real time concurrent state machines at a given time
> will be a much smaller number, as we¹ll get roughly ten to twenty events
> from the devices during the lifetime.)
>

<snap/>

It really depends on what the state machines look like, how much data
is in each one's context, how much listeners and other associated
state needs to be maintained etc. The simplest state machines can be
lightweight. Its possible to tune the datamodel to be global to reduce
memory usage (with the downsides of a global datamodel). Sometimes it
may help to pool state machines executors. Executors are serializable,
any other persistence mechanism can be implemented as an
application-specific solution per taste. There have been some recent
discussions on this topic. You can try to look through the list
archives here [4]. Here is a pointer to one such thread:

  http://markmail.org/thread/7rzalbdmbtvhr4kq

-Rahul

[1] http://commons.apache.org/scxml/guide/custom-actions.html
[2] http://commons.apache.org/scxml/guide/contexts-evaluators.html
[3] http://commons.apache.org/scxml/0.9/apidocs/org/apache/commons/scxml/EventDispatcher.html
[4] http://commons.markmail.org/


> Thanks for your advises, as always that kind of questions in project start
> time are key for future scalability
>
> Cedric NICOLAS
> Ville Fluide
>

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

[Cedric NICOLAS]

Rahul,

Thanks a lot for this long and very precise answer and for the time taken to
think about it.

I¹ve just 2 or 3 clarifications questions about the following line of codes
you¹ve proposed :

        <send target="scheme://foo.bar/master" targettype="x-mobile"
              event="device.register" namelist="myname myaddress"/>

Why do you use an url-like syntax for target. Our target is an SCXMLExecutor
instance representing the master machine. How to link this url with that
instance ? I do not understand exactly the send parameters description in
documentation.

  <send target="registry.device1" targettype="x-mobile"
        event="device.beep" namelist="beepduration"/>
  <!-- registry.device1 may return scheme://foo.bar/device1
       for instance -->

In the same idea, this line seems to address by its name the device #1. You
say registry.device1 may return //foo.bar/device1 But how and where does
this translation occurs ? Here of course the target will be the
SCXMLExecutor instance of device1.

Other (and last!) question :

You also suggest that registry would have to be stored in root context. I
suppose through Context class APIs. What are the benefits to do this instead
of using a Java code like HashMap to do this, triggered by the event above ?
Manipulating variables contents through XML is not so easy and readable if
we manage collection of objects, and may be not very optimized.

Thanks a lot for support.

Regards,

-----Original Message-----
From: Rahul Akolkar [mailto:rahul.akolkar@...]
Sent: jeudi 2 juillet 2009 19:34
To: Commons Users List
Subject: Re: [SCXML] Synchronizing state matchines

On Mon, Jun 29, 2009 at 7:05 PM, Cedric
NICOLAS<cedric.nicolas@...> wrote:

> Hi everybody,
>
> We are starting to use SCXML and Java implementation to set up state
> machines that represent a coordinated network of mobile devices. We
> are using a master state machine that acts as a coordinator and many
> identical state machines that represent the mobile devices coordinated
> by the master one.
>
> The master SM changes of states according to different states of the
> devices state machines, with some complex coordination conditions.
>
> I¹ve two questions related to this :
>
> * as our project will integrate an increasing and important number of
> states, transitions and events for the device states machines, we
> would like to avoid at maximum to use Java for describing the states
> and event flow, but do that in SCXML. Reason is maintainability and
> readability of code. How to trigger easily events to device states
> machines from the master state machine or the opposite ? More
> precisely, how to reference in the master state machine the associated
> devices state machines ? Each device state machine has a different
> SCXMLExecutor instance and context , as they of course might be in
> different states at one specific moment. But how  to trigger events in
> XML file  from one state machine to other states machines like
> (master->device, device->master, device->device events)  ? It seems
> that the target field is to be used for this, but how to reference
> other state machines from the XML file ? Of course we know how to do
> this in Java code, but triggering events as well as from Java code and
> from XML code, increase a lot the tuning of the whole system, as it¹s

becoming confusing to understand who triggers what and when, when state
machine becomes complex.
<snip/>

Yup, the idea is to model these interaction patterns as SCXML actions
(standard or custom [1]) so that these become a little more declarative, and
more importantly, can be expressed in the SCXML document itself rather than
auxiliary procedural code. Some brainstorming in terms of the scenario
above:

 * The master state machine needs to be a well-known endpoint (could be
REST, webservice, any addressing means that make sense) for all the mobile
devices that want to coordinate. The master state machine perhaps needs to
be instantiated first, though with timeouts and retries things can also be
managed either way.

 * When a device's state machine comes up, one of the first things to do
would be to send a registration event to the master. The purpose of this
event would be to enable the master in addressing the device, either
directly or via a local proxy that gets injected as part of the event
payload -- again, the addressing scheme and registration mechanism are
completely application-specified, and very likely the master state machine
will hold some sort of device registry in its
(root) context [2]. The master may complete the handshake with an ack before
the device does anything else. Beyond that, events can flow either way.

 * Now coming to the question of expressing all this in the various SCXML
document(s). Since you already know the recipe in Java code, we just need to
package it as a parameterized SCXML action. The SCXML <send> standard action
is designed for such communication (you can always use your own custom
action to further specialize any of this processing, but lets see how this
will work with <send> here). Lets say the well-known endpoint for the master
is the fictitious "scheme://foo.bar/master", then all device state machines
may boot like so:

  <scxml ... initial="register">

    <state id="register">
      <onentry>
        <send target="scheme://foo.bar/master" targettype="x-mobile"
              event="device.register" namelist="myname myaddress"/>
        <!--
            'x-mobile' is a custom targettype, though x-* is generally
            discouraged scheme these days, you can use some such name.
            'myname' and 'myaddress' are variables in this context
            contain this state machine's info that the master can use.
            There could be more than two pieces of information that gets
            sent here ofcourse (whatever is needed).
        -->
      </onentry>
      <transition target="..."/>
    </state>

    <!-- The rest of the device state machine -->

  </scxml>

(you may need to single quotes literals depending on expression language in
use throughout these snippets, so target="'scheme://foo.bar/master'" rather
than target="scheme://foo.bar/master" if needed)

The Java code that does the actual work now needs to be packaged as part of
the EventDispatcher [3] that gets registered with this device's state
machine.

In the master state machine, the above event may be captured by a transition
in a top level state like so:

  <scxml ... initial="master">

    <state id="master">

      <transition event="device.register">
        <my:register name="_eventdata.myname"
address="_eventdata.myaddress"/>
        <!-- All the registration bits, including the ack may be handled
             by the above custom action, for example -->
      </transition>

      <!-- The master state machine -->
    </state>

  </scxml>

Likewise, the master state machine will have a similar EventDispatcher that
will allow it to send events to the devices.

  <send target="registry.device1" targettype="x-mobile"
        event="device.beep" namelist="beepduration"/>
  <!-- registry.device1 may return scheme://foo.bar/device1
       for instance -->

Device to device events then with some sharing of the device registry that
is currently with the master (update events could be multicast, broadcast or
anycast per design when devices come on and drop off).

> * we may have a quite important number of device state machines
> running simultaneously (thousands) coordinated by several independent
> master state machines. Has anyone have experience of performance
> bottlenecks of such an architecture, as we will have to react in quite
> short response time to the device events ? In other words, if we load
> in memory thousands of state machines (typical life time of one device
> state machine will be between one and two hours), will we face
> important memory consumptions problems ? A solution based on data base
> persistent state machines, loaded on request when we got an event,
> then updated in database and released from memory wouldn¹t be better ?  
> (real time concurrent state machines at a given time will be a much
> smaller number, as we¹ll get roughly ten to twenty events from the
> devices during the lifetime.)
>

<snap/>

It really depends on what the state machines look like, how much data is in
each one's context, how much listeners and other associated state needs to
be maintained etc. The simplest state machines can be lightweight. Its
possible to tune the datamodel to be global to reduce memory usage (with the
downsides of a global datamodel). Sometimes it may help to pool state
machines executors. Executors are serializable, any other persistence
mechanism can be implemented as an application-specific solution per taste.
There have been some recent discussions on this topic. You can try to look
through the list archives here [4]. Here is a pointer to one such thread:

  http://markmail.org/thread/7rzalbdmbtvhr4kq

-Rahul

[1] http://commons.apache.org/scxml/guide/custom-actions.html
[2] http://commons.apache.org/scxml/guide/contexts-evaluators.html
[3]
http://commons.apache.org/scxml/0.9/apidocs/org/apache/commons/scxml/EventDi
spatcher.html
[4] http://commons.markmail.org/


> Thanks for your advises, as always that kind of questions in project
> start time are key for future scalability
>
> Cedric NICOLAS
> Ville Fluide
>

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

[Rahul Akolkar]

On Thu, Jul 2, 2009 at 6:55 PM, Cedric
NICOLAS<cedric.nicolas@...> wrote:

> Rahul,
>
> Thanks a lot for this long and very precise answer and for the time taken to
> think about it.
>
> I¹ve just 2 or 3 clarifications questions about the following line of codes
> you¹ve proposed :
>
>        <send target="scheme://foo.bar/master" targettype="x-mobile"
>              event="device.register" namelist="myname myaddress"/>
>
> Why do you use an url-like syntax for target. Our target is an SCXMLExecutor
> instance representing the master machine. How to link this url with that
> instance ?

<snip/>

I made no assumptions about the distribution model here. In a model
where not all the state machines can be referenced locally (in the
same JVM), the URL syntax in the above lines was meant to signify
endpoints for each of the state machines (in that scenario, the
EventDispatchers would speak to the local state machine on one end and
these endpoints or their proxies on the other). Ofcourse, if direct
references to all SCXMLExecutor instances are available, then the
scheme would be to use those directly so the URL syntax will not apply
(i.e. myaddress would be a reference to the device's executor
instance).


> I do not understand exactly the send parameters description in
> documentation.
>
<snap/>

When using custom targettypes (such as above), its really upto the
EventDispatcher to define the semantics of the parameters in the
namelist. In the above lines, I was sketching out a scenario where the
<send> would cause an event (i.e. TriggerEvent instance) with name
'device.register' to be triggered on the appropriate state machine and
its payload would be a map with two keys 'myname' and 'myaddress' and
corresponding values which would be picked up from the originating
state machine's (the one which contains the <send>) context. See how
this matches up with the _eventdata expressions within the
<transition> gating on event 'device.register' in the destination
state machine below.

>  <send target="registry.device1" targettype="x-mobile"
>        event="device.beep" namelist="beepduration"/>
>  <!-- registry.device1 may return scheme://foo.bar/device1
>       for instance -->
>
> In the same idea, this line seems to address by its name the device #1. You
> say registry.device1 may return //foo.bar/device1 But how and where does
> this translation occurs ? Here of course the target will be the
> SCXMLExecutor instance of device1.
>

<snip/>

Yup, if local, indeed. In the expression 'registry.device1',
'registry' would be a Map in the state machine's context whose keys
are device logical names and values are references to SCXMLExecutors
(or URLs that point to the remote state machine endpoints in a
distributed scenario).


> Other (and last!) question :
>
<snap/>

Theres no limit, keep'em coming :-)


> You also suggest that registry would have to be stored in root context. I
> suppose through Context class APIs. What are the benefits to do this instead
> of using a Java code like HashMap to do this, triggered by the event above ?
> Manipulating variables contents through XML is not so easy and readable if
> we manage collection of objects, and may be not very optimized.
>
<snip/>

The XML for actions is simply a reusable patten extracted from
procedural code (and implemented as such, so manipulation is none the
harder or easier). To add some more detail, the registry would be a
Map stored in the root context like so (when the executor is
initialized):

  executor.getRootContext().set("registry", new HashMap());

Now, the following <my:register> action's execute(...) method would
complete the registration by accessing the above Map:

  <transition event="device.register">
    <my:register name="_eventdata.myname"
                 address="_eventdata.myaddress"/>
  </transition>

  public class RegisterAction extends Action {
      ...
      public void execute(..., SCInstance si, ...) {
          Map registry = si.getRootContext().get("registry");
          registry.put(this.name, this.address);
          // send an ack, whatever else is needed
      }
  }

-Rahul

> Thanks a lot for support.
>
> Regards,
>
>
> -----Original Message-----
> From: Rahul Akolkar [mailto:rahul.akolkar@...]
> Sent: jeudi 2 juillet 2009 19:34
> To: Commons Users List
> Subject: Re: [SCXML] Synchronizing state matchines
>
> On Mon, Jun 29, 2009 at 7:05 PM, Cedric
> NICOLAS<cedric.nicolas@...> wrote:
>> Hi everybody,
>>
>> We are starting to use SCXML and Java implementation to set up state
>> machines that represent a coordinated network of mobile devices. We
>> are using a master state machine that acts as a coordinator and many
>> identical state machines that represent the mobile devices coordinated
>> by the master one.
>>
>> The master SM changes of states according to different states of the
>> devices state machines, with some complex coordination conditions.
>>
>> I¹ve two questions related to this :
>>
>> * as our project will integrate an increasing and important number of
>> states, transitions and events for the device states machines, we
>> would like to avoid at maximum to use Java for describing the states
>> and event flow, but do that in SCXML. Reason is maintainability and
>> readability of code. How to trigger easily events to device states
>> machines from the master state machine or the opposite ? More
>> precisely, how to reference in the master state machine the associated
>> devices state machines ? Each device state machine has a different
>> SCXMLExecutor instance and context , as they of course might be in
>> different states at one specific moment. But how  to trigger events in
>> XML file  from one state machine to other states machines like
>> (master->device, device->master, device->device events)  ? It seems
>> that the target field is to be used for this, but how to reference
>> other state machines from the XML file ? Of course we know how to do
>> this in Java code, but triggering events as well as from Java code and
>> from XML code, increase a lot the tuning of the whole system, as it¹s
> becoming confusing to understand who triggers what and when, when state
> machine becomes complex.
> <snip/>
>
> Yup, the idea is to model these interaction patterns as SCXML actions
> (standard or custom [1]) so that these become a little more declarative, and
> more importantly, can be expressed in the SCXML document itself rather than
> auxiliary procedural code. Some brainstorming in terms of the scenario
> above:
>
>  * The master state machine needs to be a well-known endpoint (could be
> REST, webservice, any addressing means that make sense) for all the mobile
> devices that want to coordinate. The master state machine perhaps needs to
> be instantiated first, though with timeouts and retries things can also be
> managed either way.
>
>  * When a device's state machine comes up, one of the first things to do
> would be to send a registration event to the master. The purpose of this
> event would be to enable the master in addressing the device, either
> directly or via a local proxy that gets injected as part of the event
> payload -- again, the addressing scheme and registration mechanism are
> completely application-specified, and very likely the master state machine
> will hold some sort of device registry in its
> (root) context [2]. The master may complete the handshake with an ack before
> the device does anything else. Beyond that, events can flow either way.
>
>  * Now coming to the question of expressing all this in the various SCXML
> document(s). Since you already know the recipe in Java code, we just need to
> package it as a parameterized SCXML action. The SCXML <send> standard action
> is designed for such communication (you can always use your own custom
> action to further specialize any of this processing, but lets see how this
> will work with <send> here). Lets say the well-known endpoint for the master
> is the fictitious "scheme://foo.bar/master", then all device state machines
> may boot like so:
>
>  <scxml ... initial="register">
>
>    <state id="register">
>      <onentry>
>        <send target="scheme://foo.bar/master" targettype="x-mobile"
>              event="device.register" namelist="myname myaddress"/>
>        <!--
>            'x-mobile' is a custom targettype, though x-* is generally
>            discouraged scheme these days, you can use some such name.
>            'myname' and 'myaddress' are variables in this context
>            contain this state machine's info that the master can use.
>            There could be more than two pieces of information that gets
>            sent here ofcourse (whatever is needed).
>        -->
>      </onentry>
>      <transition target="..."/>
>    </state>
>
>    <!-- The rest of the device state machine -->
>
>  </scxml>
>
> (you may need to single quotes literals depending on expression language in
> use throughout these snippets, so target="'scheme://foo.bar/master'" rather
> than target="scheme://foo.bar/master" if needed)
>
> The Java code that does the actual work now needs to be packaged as part of
> the EventDispatcher [3] that gets registered with this device's state
> machine.
>
> In the master state machine, the above event may be captured by a transition
> in a top level state like so:
>
>  <scxml ... initial="master">
>
>    <state id="master">
>
>      <transition event="device.register">
>        <my:register name="_eventdata.myname"
> address="_eventdata.myaddress"/>
>        <!-- All the registration bits, including the ack may be handled
>             by the above custom action, for example -->
>      </transition>
>
>      <!-- The master state machine -->
>    </state>
>
>  </scxml>
>
> Likewise, the master state machine will have a similar EventDispatcher that
> will allow it to send events to the devices.
>
>  <send target="registry.device1" targettype="x-mobile"
>        event="device.beep" namelist="beepduration"/>
>  <!-- registry.device1 may return scheme://foo.bar/device1
>       for instance -->
>
> Device to device events then with some sharing of the device registry that
> is currently with the master (update events could be multicast, broadcast or
> anycast per design when devices come on and drop off).
>
>
>> * we may have a quite important number of device state machines
>> running simultaneously (thousands) coordinated by several independent
>> master state machines. Has anyone have experience of performance
>> bottlenecks of such an architecture, as we will have to react in quite
>> short response time to the device events ? In other words, if we load
>> in memory thousands of state machines (typical life time of one device
>> state machine will be between one and two hours), will we face
>> important memory consumptions problems ? A solution based on data base
>> persistent state machines, loaded on request when we got an event,
>> then updated in database and released from memory wouldn¹t be better ?
>> (real time concurrent state machines at a given time will be a much
>> smaller number, as we¹ll get roughly ten to twenty events from the
>> devices during the lifetime.)
>>
> <snap/>
>
> It really depends on what the state machines look like, how much data is in
> each one's context, how much listeners and other associated state needs to
> be maintained etc. The simplest state machines can be lightweight. Its
> possible to tune the datamodel to be global to reduce memory usage (with the
> downsides of a global datamodel). Sometimes it may help to pool state
> machines executors. Executors are serializable, any other persistence
> mechanism can be implemented as an application-specific solution per taste.
> There have been some recent discussions on this topic. You can try to look
> through the list archives here [4]. Here is a pointer to one such thread:
>
>  http://markmail.org/thread/7rzalbdmbtvhr4kq
>
> -Rahul
>
> [1] http://commons.apache.org/scxml/guide/custom-actions.html
> [2] http://commons.apache.org/scxml/guide/contexts-evaluators.html
> [3]
> http://commons.apache.org/scxml/0.9/apidocs/org/apache/commons/scxml/EventDi
> spatcher.html
> [4] http://commons.markmail.org/
>
>
>> Thanks for your advises, as always that kind of questions in project
>> start time are key for future scalability
>>
>> Cedric NICOLAS
>> Ville Fluide
>>
>

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