commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rahul Akolkar (JIRA)" <j...@apache.org>
Subject [jira] Updated: (SCXML-112) Wrong behavior if event is triggered from EventDispatcher
Date Fri, 17 Jul 2009 06:44:14 GMT

     [ 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.


Mime
View raw message