commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ales Dolecek (JIRA)" <>
Subject [jira] Commented: (SCXML-112) Wrong behavior if event is triggered from EventDispatcher
Date Sat, 18 Jul 2009 22:46:14 GMT


Ales Dolecek commented on SCXML-112:

No, no - that is fine. I understand that the project has it's history and that it is hard
to keep up with changing "standard". I'm just not up to made the changes and actually externalize
the queue since I'm just starting to dig into commons-scxml internals and my attempt to "fix"
this issue grew fast out of my time and skills. :-(

> Wrong behavior if event is triggered from EventDispatcher
> ---------------------------------------------------------
>                 Key: SCXML-112
>                 URL:
>             Project: Commons SCXML
>          Issue Type: Bug
>            Reporter: Ales Dolecek
>             Fix For: 1.0
>         Attachments:, test1.xml, test2.xml
> Method SCMLExecutor#triggerEvents is synchronized which is too naive way to ensure that
events are processed in order they arrive.
> Since the callback to EventDispatcher is made by thread that holds lock on SCMLExecutor
triggering event from the dispatcher allows this thread to re-enter the event handling.
> Note: This has nothing to do with multi-threading since there is only one thread.
> Simple queue might e sufficient but in multi-threaded application would make the first
thread to enter #triggerEvents process events from other threads queued while the method is
> Another approach might be to call EventDispatcher in separate thread,but it has it's
drawbacks too:
> a) changes single-threaded application into-multithreaded which might break assumtions
made by unaware user
> b) might start too many threads
> c) Java does not guarantee that threads waiting for lock will get it in same order as
they arrive => might result in non-deterministic behavior of SCXML interpretation
> Possible solutions would be:
> 1) add queue and allow the "first" thread server all events - might be just fine since
multi-threaded applications might create dedicate thread just for SCXML imterpretation
> 2) add queue and block threads after they queue event - so they "wait" until execute
their event become first in queue
> 3) factor out the queue event queue management and allow for "pluggable" strategy

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message