[cdi-dev] Update on Async event doc
jharting at redhat.com
Tue Mar 17 02:27:33 EDT 2015
On 03/16/2015 05:19 PM, Antoine Sabot-Durand wrote:
>> Le 16 mars 2015 à 10:33, Jozef Hartinger <jharting at redhat.com
>> <mailto:jharting at redhat.com>> a écrit :
>> On 03/12/2015 01:56 PM, Antoine Sabot-Durand wrote:
>>> Hi all,
>>> I compiled all the feedback and decision we took regarding async
>>> events and updated the Google Doc :
>>> 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.
> We’re saying the same : these will come from the specified behavior ;)
>>> 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?
> suggestion are welcome. How could we handle multiple exception at the
> caller level ?
I don't know. How did you plan to handle those in your proposal?
>>> 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.
> That’s why your input is precious, previous discussion brought us with
> the opposite pov. Personally the simpler to implement is the right
No, I mean simpler to explain and for users to take in. Implementation
complexity is way less important.
>>> 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
>>> cdi-dev mailing list
>>> cdi-dev at lists.jboss.org
>>> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the cdi-dev