[
https://issues.apache.org/jira/browse/SCXML-112?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13824198#comment-13824198
]
Woonsan Ko commented on SCXML-112:
----------------------------------
Hi,
I've just met this issue while looking into the internal Send action behavior.
IIUC, then I think there are two improvement ideas here:
1 - to queue the events and execute event in order
2 - hopefully to have a new EventDispatcher implementation (maybe using
ScheduledThreadPoolExecutor for instance)
IMO, the first one is more important because it guarantees the execution order.
The second one is still possible if a custom one is provided for their domain.
To simply fix the first one, I think we can improve SimpleDispatcher to inject
an event queue instance (e.g, EventQueue interface) or create a default
implementation (e.g, SimpleEventQueue) and SimpleDispatcher#send() can simply
push the event into the event queue instance first and try to poll/execute all
the remaining events afterward.
Then I think the SimpleDispatcher will perform more correctly even though it is
still a trivial and simple implementation (as intended).
The second improvement idea (another EventDispatcher implementation) can be
another JIRA issue.
What do you think?
Regards,
Woonsan
> Wrong behavior if event is triggered from EventDispatcher
> ---------------------------------------------------------
>
> Key: SCXML-112
> URL: https://issues.apache.org/jira/browse/SCXML-112
> Project: Commons SCXML
> Issue Type: Bug
> Reporter: Ales Dolecek
> Fix For: 2.0
>
> Attachments: Dispatcher.java, 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 running.
> 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 was sent by Atlassian JIRA
(v6.1#6144)
