commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "r.c.hoekstra" <>
Subject Re: [scxml] looking for developer for adaptations on Commons SCXML
Date Thu, 30 Nov 2017 09:50:48 GMT
On 30-11-17 01:49, Woonsan Ko wrote:

Hi Woonsan,

I'll go through your comments in the text below.

> On Wed, Nov 29, 2017 at 6:56 AM, r.c.hoekstra <> wrote:
>> Hi List,
>> We are working at the ErasmusMC hospital at Rotterdam, Netherlands, on
>> scientific simulations on the spread of infectious diseases through human
>> populations.
>> In this project we use Apache Commons SCXML to model diseases.
> Just out of curiosity, would you mind sharing the reasons, in higher
> level, why SCXML library was chosen for the simulation in the first
> place? There are many tools and libs, specialized in simulation, such
> as MASON. Was it mainly because of the declarative way of SCXML or
> scriptability (e.g, in JEXL) or both? Is there any other background
> reason?
Yes. The declarativeness was really important. We needed a way to 
declare the disease processes from state to state,
with transitions. And as we were already using other xml files to define 
other input (population, etc), it fitted the rest
of the input perfectly.
Besides that, we also use the scripting. We use JEXL for that.

> Is it also a considerable option for you to use one of those
> simulation-specialized tools or libs instead of SCXML if it can meets
> the requirements?
Yes we looked into a few of those; I know there are many of them. For 
various reasons it mostly prooved better to develop our own libraries.
But I must confess that I didn't look in those libraries for scxml-like 
I supposed that it would not support that.
>> However, the problem with the present implementation is that it is too slow
>> for us. We would need a version that is optimized for being instantiated
>> 1000000 times in a running simulation.
> It sounds really really slow, and the expectation is like 10+ days vs
> 1 sec. And is it concerned more on *loading* time before *execution*,
> or both?

Well, a million might be a bit exagerated for now, but eventually that 
is what we'd like. A run with about 50.000 takes
2 hours or so to run, if I remember it well. We'd like to scale that up 
to at least a few hundreds of thousands, without
having to wait for hours or without the JVM crashing on out of memory 
And indeed, both loading and execution do matter. A state machine is 
attached to a person, and persons may be born
during a simulation, so that involves instantiating/loading a new state 
machine. But then, the runtime of a simulation is
no extremely long in comparison to the life expectancy of persons (about 
200 years or so).

>> For the coming 2 or 3 months we have money available to pay someone who
>> could create an adapted, descaled version of apache commons scxml. The goal
>> is to make it much faster, either by optimizing, rewriting, and dispose of
>> elements not needed for us.
> To be honest, in my gut feeling, it seems infeasible to improve or
> rewrite the SCXML library in the shorter term to meet the expectation.
> To me, SCXML in both spec and implementation, doesn't seem to be
> designed for that kind of highly capable simulation use cases. It's
> just too heavy and too much feature driven, IMHO, for that kind of use
> cases. Please correct me if I'm wrong.
No, I think you're right. It isn't designed to be instantiated many times.
Maybe my wording was not chosen well enough. We're not exactly 
interested in
rewriting the SCXML library. There are quite some features of it we 
don't use at all, for
example the data model. We would want a stripped down "version" which is 
for efficiently firing many copies, which uses the declarative features, 
but which has dropped
features which we didn't use anyway. If that still would meet the 
official set of features that
defines scxml isn't really a concern.

> Also, I'm personally doubtful to try to improve SCXML project to cover
> the simulation use cases even in the future. It is a reference
> implementation and so it has to keep all the features in the spec, and
> so on. Long-time less-activeness in this community is another thing.
> Regards,
> Woonsan
>> Our preference would be to find someone who has developed for the commons
>> scxml project, or who is at least an experienced user.
>> In case of anyone interested please reply via this list and we can get into
>> contact about the details.
>> best regards,
>> Rinke Hoekstra
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message