[cdi-dev] Update on Async event doc

[Jozef Hartinger]

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 : 
>>> https://docs.google.com/document/d/1Tm_fZWS6569YqCH9lGxuqBGzS9gfupic-vv1dyKCUxk/edit?usp=sharing
>>>
>>> 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 at 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.
>>
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150317/8cbf2627/attachment.html