On 03/16/2015 05:19 PM, Antoine Sabot-Durand wrote:
> Le 16 mars 2015 à 10:33, Jozef Hartinger <jharting(a)redhat.com
> <mailto:jharting@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 :
>>
https://docs.google.com/document/d/1Tm_fZWS6569YqCH9lGxuqBGzS9gfupic-vv1d...
>>
>> 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
choice...
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
>>
>>
>> Antoine
>>
>>
>>
>> _______________________________________________
>> cdi-dev mailing list
>> cdi-dev(a)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.
>
>