[scxml] Re: our project setup: any tips specifically on performance/speed?

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

[scxml] Re: our project setup: any tips specifically on performance/speed?

rinke
Hi Woonsan, Hi Ate,

(sorry for the late response)

Woonsan wrote:

> If the estimate of the pure SCXML executions can possibly meet your requirements, then I think
> the next thing to consider might be how to reduce IOs if you have to (de)serialize those instances.
> In one of our projects, we initialize a root context and an executor every time before triggering
> events. So, the SCXML definition is responsible for initializing itself (to move the right
> current state) from the given root context (in script blocks). I think this pattern could
> help reduce the amount of (de)serialized data, and so reduce IO.

We haven't given the (de)serialization lots of attention yet. Of course, potentially it can be quite heavy with a few 100.000 of instances, but I don't know yet what is exactly needed.
Your pattern sounds interesting, but can you please point out some link to that project, so I can get the real picture clear?

thanks for the response,

Rinke

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [scxml] Re: our project setup: any tips specifically on performance/speed?

Woonsan Ko-2
Hi Rinke,


On Friday, May 30, 2014 4:46 PM, R.C. Hoekstra <[hidden email]> wrote:


>
>
>Hi Woonsan, Hi Ate,
>
>(sorry for the late response)
>
>Woonsan wrote:
>
>> If the estimate of the pure SCXML executions can possibly meet your requirements, then I think
>> the next thing to consider might be how to reduce IOs if you have to (de)serialize those instances.
>> In one of our projects, we initialize a root context and an executor every time before triggering
>> events. So, the SCXML definition is responsible for initializing itself (to move the right
>> current state) from the given root context (in script blocks). I think this pattern could
>> help reduce the amount of (de)serialized data, and so reduce IO.
>
>We haven't given the (de)serialization lots of attention yet. Of course, potentially it can be quite heavy with a few 100.000 of instances, but I don't know yet what is exactly needed.
>Your pattern sounds interesting, but can you please point out some link to that project, so I can get the real picture clear? 

Ate gave a presentation last April in Denver with Hippo CMS Document Workflow use cases and SVN location info (p15):
- http://events.linuxfoundation.org/sites/events/files/slides/ApacheConUS2014%20-%20Apache%20Commons%20SCXML%202.0.pdf

You will be able to find 'documentworkflow.scxml' and 'DocumentWorkflowImpl.java' which always invokes workflowExecutor.start() to reset the context and initialize the state without having to store the executor or instance.

Regards,

Woonsan


>
>thanks for the response,
>
>Rinke
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: [hidden email]
>For additional commands, e-mail: [hidden email]
>
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]