commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin Gainty <mgai...@hotmail.com>
Subject Re: [scxml] looking for developer for adaptations on Commons SCXML
Date Thu, 30 Nov 2017 13:26:16 GMT


________________________________
From: r.c.hoekstra <r.c.hoekstra@scarlet.nl>
Sent: Thursday, November 30, 2017 4:50 AM
To: Commons Users List
Subject: Re: [scxml] looking for developer for adaptations on Commons SCXML

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 <r.c.hoekstra@scarlet.nl> 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
features.
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
exceptions.
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
designed
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.

MG>*if* SCXML/JEXL is pegging 1+ JVM which may cause OOM or Stackoverflow errors
MG>as long as your SCXML/JEXL work-units are wholly-contained and atomic maybe zookeeper
MG>can be implemented to execute and coordinate these long-running simulations?
MG>https://zookeeper.apache.org/doc/trunk/zookeeperOver.html#ch_DesignOverview
ZooKeeper Architecture - Apache ZooKeeper - Home<https://zookeeper.apache.org/doc/trunk/zookeeperOver.html#ch_DesignOverview>
zookeeper.apache.org
ZooKeeper is a distributed, open-source coordination service for distributed applications.
It exposes a simple set of primitives that distributed applications can ...




> 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: user-unsubscribe@commons.apache.org
> For additional commands, e-mail: user-help@commons.apache.org
>
>


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


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message