[
https://issues.apache.org/jira/browse/SCXML-112?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ales Dolecek updated SCXML-112:
-------------------------------
Attachment: Dispatcher.java
test2.xml
test1.xml
Interpreting test1.xml with JEXL will end "in good-end". Interpreting test2.xml
will end in "disconnected" while "visiting" the "wrong-end" state. In both
cases the SCXMLexecutor should use attached Dispatcher which simply triggers
any event back to executor.
INFO [SimpleSCXMLListener] /initial
INFO [SimpleSCXMLListener] /initial
INFO [SimpleSCXMLListener] transition (event = start, cond = null, from =
/initial, to = /disconnected)
INFO [SimpleSCXMLListener] /disconnected
INFO [SimpleSCXMLListener] /disconnected
INFO [SimpleSCXMLListener] transition (event = event, cond = null, from =
/disconnected, to = /good-end)
INFO [SimpleSCXMLListener] /good-end
INFO [SimpleSCXMLListener] /initial
INFO [SimpleSCXMLListener] /initial
INFO [SimpleSCXMLListener] transition (event = start, cond = null, from =
/initial, to = /disconnected)
INFO [SimpleSCXMLListener] /initial
INFO [SimpleSCXMLListener] transition (event = event, cond = null, from =
/initial, to = /wrong-end)
INFO [SimpleSCXMLListener] /wrong-end
INFO [SimpleSCXMLListener] /disconnected
> 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
> 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 is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
