[
https://issues.apache.org/jira/browse/SCXML-112?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12732874#action_12732874
]
Ales Dolecek commented on SCXML-112:
------------------------------------
I'm afraid that I can't externalize the queue.
I'm sorry to say that, but the code seems "scattered". There are many
interlinked classes/interfaces which overlap eg.
Status and SCInstance
- both hold state information
SCXMLExecutor and SCInstance reference each other in 1:1 relation
- seems useless to have them separated
- might give sense if executor was intended as "driver", but then this is
purpose of the SCXMLSemantics
Also came across other issues while digging into the code:
- the events are not processed one at time but in chunks - submitting
multiple events via #triggerEvents behave differently than repeated invocation
of #triggerEvent
Factoring out the queue would mean radical changes in code and, what is worse,
also to contracts of the public APIs.
It might be possible to keep contract of SCXMLExecutor eg. by adding:
#microStep() and #macroStep() methods and let
a) triggerEvents
- lock external queue, enqueue all queued events and then call, get it's
size, unlock it and call #macroStep "size" times so that it process all
currently queued external events plus the ones added by the invocation
b) all methods invoked by SCXMLExecutor that might generate internal events
must have access to the internalQueue => pass along SCInstance (if the queue
would be there)
c) all methods that take TriggerEvent[] should be rewriten so theat they take
just TriggerEvent
- or ensure that they are invoked with array of lenght == 1
---
The API deserve major revision/rethink
> 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.
