[
https://issues.apache.org/jira/browse/ISIS-1045?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14333153#comment-14333153
]
Oscar Bou commented on ISIS-1045:
---------------------------------
COMMENTS FOR GUAVA EVENT BUS
The per-thread queueing behavior is irrespective of using the EventBus or the
AsyncEventBus implementation.
Notice on [1] the definition of the queue.
And on [2] the logic of the "dispatch" method, that originates the problem, as
it will introduce different behavior depending on its internal state when a new
Event is posted to be dispatched:
- If it's currently dispatching a previously posted Event, it will queue it, so
its event handlers will be invoked after previously invoking all event handlers
of this previous event.
- If it's not currently dispatching any other Event, it will instead invoke all
its event handlers immediately.
I've just noticed on [3] the availability of an "immediate" Service Bus, whose
comment is that it will not queue Events. So perhaps this could be a simpler
solution. But not sure if the ServiceBus can be configured to use this
Dispatcher instead of the "queue" one ... Perhaps simply creating a custom
EventBus inheriting from the current one, which overrides the Dispatcher
configured at [4]? Look there how it currently instantiates the
"queuePerThread" dispatcher ...
[1]
https://code.google.com/p/guava-libraries/source/browse/guava/src/com/google/common/eventbus/Dispatcher.java#87
[2]
https://code.google.com/p/guava-libraries/source/browse/guava/src/com/google/common/eventbus/Dispatcher.java#96
[3]
https://code.google.com/p/guava-libraries/source/browse/guava/src/com/google/common/eventbus/Dispatcher.java#63
[4]
https://code.google.com/p/guava-libraries/source/browse/guava/src/com/google/common/eventbus/EventBus.java#119
> New domain events are created for each phase for properties, but not for
> collections nor actions. The current design doesn't support use of the
> wrapper factory.
> -----------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: ISIS-1045
> URL: https://issues.apache.org/jira/browse/ISIS-1045
> Project: Isis
> Issue Type: Improvement
> Components: Core
> Affects Versions: core-1.7.0
> Reporter: Dan Haywood
> Assignee: Dan Haywood
> Priority: Minor
> Fix For: core-1.9.0
>
>
> In the domain events design we have 5 phases:
> hide/disable/validate/pre-execute/post-execute. The framework attempts to
> reuse the same event where possible
> for actions:
> - for hide, always creates new event
> - for disable, always creates new event
> - for validate, always creates new event, puts onto thread-local
> - for pre-execute, uses the event from validate (obtain from thread-local)
> - for post-execute, uses the event from pre-execute (passed as local var).
> for collections:
> - ditto
> but for properties, although we originally had the same algorithm, this was
> changed (patch from Oscar) to:
> - for hide, always creates new event
> - for disable, always creates new event
> - for validate, always creates new event, puts onto thread-local
> - for pre-execute, always creates a new event (ignores that on thread-local)
> - for post-execute, uses the event from pre-execute (passed as local var).
> The reason that Oscar needed this change was because the framework does not
> anticipate there being more than one "pending" interaction. However, if the
> wrapper factory is used, then this assumption isn't true, because validateX()
> -> wrap -> validateY().
> This use case actually needs a stack of pending interaction events to support
> this change.
> As things stand:
> * the getUserData() functionality is broken for property domain events
> * the underlying problem remains for actions -> actions using the wrapper
> factory during the validate phase.
> There is also a suggestion that the Guava event bus might be an issue in that
> it buffers changes; I'm not exactly sure what this means (we don't use the
> async guava bus), and I don't know if its behaviour is significant or not.
> But in any case, the above design defect is an issue irrespective and which
> needs addressing; once that's fixed then we can look at the Guava event bus
> to decide if it is also a problem for us or not.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
