[
https://issues.apache.org/jira/browse/SCXML-112?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rahul Akolkar updated SCXML-112:
--------------------------------
Fix Version/s: 1.0
The current behavior is very much so by design. As you've well articulated in
your comments, there are trade-offs and in the end the drawbacks of always
spawning a thread for the EventDispatcher / Invoker / SCXMLListener outweigh
any benefits (especially when users can still choose to do some processing
asynchronously per application needs). In many container environments, a very
large number of SCXML instances are live in the same JVM (furthermore, any
<onentry>, <onexit> or <transition> may have multiple <send>s for example) so
we have to take a resource-conservative approach.
In fact, executable content (which includes <send>) is supposed to take
negligible amount of time (tending to zero) in state chart theory. So, in
general, the EventDispatcher shouldn't do anything that takes noticeable amount
of time. However, a pragmatic view suggests that sometimes a bit of processing
is helpful in executable content, and when that happens doing it asynchronously
is always possible as application choice.
Furthermore, using the EventDispatcher, Invokers or SCXMLListeners to
immediately trigger events to the originating/host state machine is generally
an anti-pattern (they may ofcourse do so to report the result of some
processing). The recommended way for adding immediate events to the queue is
through use of <send> with no target and type "SCXML". These entities should
also use something like the AsyncTrigger when needed (though now that I'm
pointing to it, I can spot a couple of improvements):
http://svn.apache.org/repos/asf/commons/proper/scxml/trunk/src/main/java/org/apache/commons/scxml/invoke/AsyncTrigger.java
So your attached Dispatcher would do something similar. I did try to understand
the rest of your test cases (but test1.xml and test2.xml seem very similar --
except one has <send> attribute "targettype" and the other just has "type").
It'd be great if you could please attach complete JUnit tests so its easy to
run these without guesswork. There are many helper methods in SCXMLTestHelper
class which make the JUnit tests quite brief (and therefore, hopefully quick to
author).
In terms of action items, perhaps it may make sense to add something like the
AsyncTrigger as a public class in the v1.0 timeframe. It may also make sense to
improve the documentation by adding, say a section to the user guide on the
website about triggering events back on the originating executor.
> 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: 1.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 is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
