On 03/12/2015 01:56 PM, Antoine
Sabot-Durand wrote:
Hi all,
The following point stays open. I’d like to close
them (if possible) during the next meeting on Tuesday
1) Async delivery mechanism (comment by Jozef)
Should we write in the spec about how threads for
events delivery should be used? Personally I’d rather not: I
think this should be let to implementation, the specification
should only describe the expected behavior (concurrency or not).
now I may have missed something.
We should not specify technical details assuming we clearly define
what guarantees are/are not available regarding ordering,
visibility, concurrency, effects of exceptions,
CDI/security/transactional context propagation and perhaps others I
missed.
2) Exception Handling (comment by Jozef)
I didn’t write anything about exception and we
should decide what happens if an exception occurs in an observer
during async event dispatch. I think that it shouldn’t impact
other observers and that we should stick to the way
CompletionStage API works today.
What does it mean? CompletionStage API allows you to handle (a
single) Exception. Would those exceptions be swallowed or provided
to the caller somehow?
3) Async event activation on both ends
We all agree that we need to explicitly fire event
asynchronously on the producer side (fireAsync()). The
discussion in 8.1 is about adding a way to accept async call on
the consumer (observer) side.
a) As events are often triggered in other parts of
the application than the parts that consume them (most CDI
framework lib fire events foe end user code) preventing user to
decide if an observer can be called asynchronously could lead to
issues and will prevent library developper to use fireAsync()
(in a defensive coding approach).
b) On the other hand, when placed in the same
application, it’ll be very confusing for user to have to
fireAsync() and enable async observer to activate this new
feature.
I propose an opt-out approach. We add
‘asyncSupported' member to ‘@Observes' annotation with ‘true’ as
default value. So in case of b) the end user won’t have to
explicitly activate async on observer and i case of a) user
detecting issue coming from async treatment of an event can
explicitly declares one or more observer not compatible with
async resolution with @Observes(asyncSupported=False)
4) Support observer ordering with async events
I think we should keep event ordering for
synchronous event and ignore this feature in async event. I
don’t see obvious use case to be async and ordered.
if an observer O1 defines priority P1 and a different observer O2
defines P2 where P2 > P1 then it probably does that for a reason.
Most likely because O2 depends on the state changes possibly
performed by O1. I think this holds true no matter if the event is
fired synchronously or asynchronously. Therefore, I think we should
respect priority in both cases.
In addition, the observer ordering concept will be simpler if we
treat observers the same way in both sync and async.
5) Context propagation
I understand that propagating contexts in async
event would impact easily context API. My only concern here is
to be define async event to keep this feature possible.
If I forgot points please comment this mail and the
doc so we can take final decision during next meeting.
Thank you
Antoine
_______________________________________________
cdi-dev mailing list
cdi-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/cdi-dev
Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.