[
https://issues.apache.org/jira/browse/SCXML-112?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12732628#action_12732628
]
Rahul Akolkar commented on SCXML-112:
-------------------------------------
OK, great, with that clarification for the test SCXML documents, the tests and
comments make sense. What I didn't get around to mentioning in my last comment
was that we've always said that users should set up an external event queue as
a feeder to the SCXMLExecutor instances (using an appropriate implementation
that makes sense for their application domain).
Towards that end, I agree that having something along the lines of option (3)
mentioned in your initial post to this issue i.e. factor out the queue event
queue management and allow for "pluggable" strategy, seems like a reasonable
addition at this time. We would want to be able to allow for any number of
queueing solutions/implementations. For example, using
ScheduledThreadPoolExecutor as you mention may be one basis. Note that SCXML
trunk is JDK 1.4 based, though we can definitely add such a solution in the J6
branch. So I think this is open to code proposals, any proposal via patch(es)
welcome.
> 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.
