[
https://issues.apache.org/jira/browse/SCXML-112?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12732403#action_12732403
]
Ales Dolecek commented on SCXML-112:
------------------------------------
Sorry - the difference between the files SHOULD be the type - not name of the
attribute - but it's name but it's value. (I have edited the file in-place and
made 2 versions just for the report - apparently wrong). When "scxml" is used
the SCXMLExecutor handles the event by itself and everything works fine. When
"non-scxml" is used the SCXMLExecutor calls EventDispatcher which calls back
#triggerEvent. It is single thread and the call takes "neglible amount of time".
The point was to show that executor itself does not use #triggerEvents
internally.
I have no problem with the issue as I'm using ScheduledThreadPoolExecutor
(introduced in J5) which converts #send invocations into asyncronous calls and
also provides queue.
---
I'm in telephony world, which is fast, async and event based by it's nature and
is also "behind" SCXML. The dispatcher calls CTI and the results come back
asynchronously and very fast. I came acros the issue in test unit which fake
the CTI loop and fire expected events directly from dispatcher.
---
Maybe the triggering of events should be separated from it's execution. The
SCXMLExecutor might expose methods to check if there are external events in
queue and that make single macro-step. User would then call triggerEvent(...)
and "while (pendingEvents()) { step(); }". The step might have variants that
would block waiting for events (possibly with timeout).
AsyncTrigger does not solve the problem of non-derministic behavior. If you
trigger multiple AsyncTriggers you have no guarantee that they will be
processed in the order you fired them - which might be problem and violate
SCXML specification. External queue won't help since events of type "scxml"
would not use it and would skip events in the queue.
As result there is currently no way how to achive the deterministic behavior of
SCXML in multithreaded environment. And no way to correctly trigger events from
<send> or <invoke> in single-threaded environment. Both of these are however
needed to conform to SCXML as using send/invoke with wrong type MUST result in
firing error event.
---
The idea I'm trying to express, rather clumsily, is that the the SCXMLExecutor
should be designed as thread safe, or at least with thread safety "in-mind",
since the events MAY come from different "sources" and MAY do so while the
state machine is in transition.
The SCXML is multi-threaded and async by nature/design and at least
SCXMLExecutor should be as well.
> 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.
