[cdi-dev] On @Observes for async events

Pete Muir pmuir at redhat.com
Wed Mar 18 13:30:54 EDT 2015 

> On 18 Mar 2015, at 17:26, Romain Manni-Bucau <rmannibucau at gmail.com> wrote:
> 
> 
> 
> 2015-03-18 17:57 GMT+01:00 Pete Muir <pmuir at redhat.com <mailto:pmuir at redhat.com>>:
> 
>> On 18 Mar 2015, at 16:46, Antoine Sabot-Durand <antoine at sabot-durand.net <mailto:antoine at sabot-durand.net>> wrote:
>> 
>> 
>>> Le 18 mars 2015 à 17:31, Pete Muir <pmuir at redhat.com <mailto:pmuir at redhat.com>> a écrit :
>>> 
>>> Agreed, that is a mess. Why do we need to enable on both sides?
>> 
>> Glad to share this pic with you. Mark raised the problem of backward compatibility. If a 3rd party lib use fireAsync(), user have no choice to deactivate async operation on his @Observes. Imagine this observer is linked to a transaction phase, it won”t work as expected. So if we don’t give a mean to opt-in or opt-out async on observer code may break and thus 3rd party lib will never switch to fireAsync().
> 
> Ok, I’m missing a subtle point I guess. If a transaction is running, then the observer method is invoked async anyway (during the correct phase). If a transaction is not running, then it can fire async as per non transactional observers.
> 
>> We also have the problem of bean injection or bean request in the observer, as we are not sure to adopt context propagation in async operation as I’d like to, it could also break code to fore observer in async mode from outside.
> 
> I would assume that context propagation is a must.
> 
> 
> but opposed to ee concurrency utilities

I thought this was by mistake rather than design?

> and other EE parts?

Again, AIUI by mistake, not design.

> sounds weird even if tempting, maybe need a sync with other specs
>  
> However I can see that if we can’t support this, then there is a problem.
> 
>> 
>> 
>>> 
>>>> On 18 Mar 2015, at 15:36, Antoine Sabot-Durand <antoine at sabot-durand.net <mailto:antoine at sabot-durand.net>> wrote:
>>>> 
>>>> Ok guys,
>>>> 
>>>> Again, ordering here is optional. My first thought was to not support it with async events, Jozef relaunch the subject. The heart of the discussion here is “can we find a way to avoid activating async event at both ends and keep backward compatibility”. Have to use fireAsync() on one side and @Async @Observes or @Observes(asyncSupported=true) at the other side seems to me very unfriendly for users, but when I see mot people focus on other secondary points I think I’m the only one to find this crappy ;).
>>>> 
>>>> 
>>>>> Le 18 mars 2015 à 16:17, Pete Muir <pmuir at redhat.com <mailto:pmuir at redhat.com>> a écrit :
>>>>> 
>>>>> 
>>>>>> On 18 Mar 2015, at 13:04, Romain Manni-Bucau <rmannibucau at gmail.com <mailto:rmannibucau at gmail.com>> wrote:
>>>>>> 
>>>>>> 
>>>>>> 2015-03-18 13:55 GMT+01:00 Jozef Hartinger <jharting at redhat.com <mailto:jharting at redhat.com>>:
>>>>>> 
>>>>>> On 03/18/2015 01:46 PM, Romain Manni-Bucau wrote:
>>>>>>> 
>>>>>>> 2015-03-18 13:35 GMT+01:00 Jozef Hartinger <jharting at redhat.com <mailto:jharting at redhat.com>>:
>>>>>>> 
>>>>>>> On 03/18/2015 01:28 PM, Romain Manni-Bucau wrote:
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 2015-03-18 13:15 GMT+01:00 Jozef Hartinger <jharting at redhat.com <mailto:jharting at redhat.com>>:
>>>>>>>> 
>>>>>>>> On 03/18/2015 11:16 AM, Romain Manni-Bucau wrote:
>>>>>>>> sequentializing them arbitrarily just makes it not async anymore
>>>>>>>> the event firing thread won't wait for event delivery so it is still async
>>>>>>>> 
>>>>>>>> well doesn't change the fact you break original async need/wish doing it.
>>>>>>> break what?
>>>>>>> 
>>>>>>> don't wait behavior, own thread model by call which is what async means most of the time
>>>>>> Well, the thread firing an event won't wait for the observers to complete so I cannot see how it breaks your "original async need/wish". Or do you associate "async" with splitting the work into as many parallel threads as possible? If so then we have a mismatch in terminology.
>>>>> 
>>>>> FWIW this is what I would interpret an async observer model to be, yes. An async fire, perhaps not. However I think it’s unnecessarily limiting to design the ability to do this out of the spec, especially for an edge case such as asynchronous ordered observers.
>>>>> 
>>>>> If you are writing an async observer, you clearly need to make it’s functionality idempotent, or expect things to go weird.
>>>>> 
>>>>> Ordered observers are something I’m still not overly happy about ;-)
>>>>> 
>>>>>> 
>>>>>> 
>>>>>> well about terminology maybe but I more think about expected behavior as a user. Think we now both get what we each of us put behind async and question is what's the most common case. Depending where you put async (fireAsync vs @Async/@ObserveAsync)  it is not the same thing at all.
>>>>>>  
>>>>>>  
>>>>>> 
>>>>>> (+ think to the case you dont really have priorities you are just breaking the whole concept).
>>>>>> If you do not have priorities (or they are the same) then it is most likely fine to notify the observers in parallel. If you however do have priorities then it makes sense IMO to take them into account. Doing otherwise just complicates the entire concept by adding an artificial constraint.
>>>>>> 
>>>>>> 
>>>>>> point is you are introducing a model concept which is not aligned on the common model + doesn't even match correctly the async needs (what about onFailure() and onTimeout() which are mandatory when doing async)
>>>>>> what common model?
>>>>>>> 
>>>>>> callbacks one which is the only one making async usable and prod compatible
>>>>>> Which part is not aligned? In the current proposal you get a callback when all observers complete or an exception occurs. In what order the observers are called does not change anything about that.
>>>>>> 
>>>>>> you don't control the timeout and exception from the callback. I mean in the observer chain which is what is needed most of the time (it helps me to think to it with a javascript example but maybe my personal feeling).
>>>>>>  
>>>>>> 
>>>>>>>> I tend to join Mark saying we should just do the minimum instead of wanting to do to much and providing something highly broken we'll need to fix in next version with more broken patterns. What's the need is the real question, not what would be cool to implement.
>>>>>>>> 
>>>>>>>> Don't forget an async spec smells more and more strong with real async semantic and solutions so I guess the less we put in CDI now better it is.
>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> _______________________________________________
>>>>>> cdi-dev mailing list
>>>>>> cdi-dev at lists.jboss.org <mailto:cdi-dev at lists.jboss.org>
>>>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev <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 <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.
>>>>> 
>>>>> _______________________________________________
>>>>> cdi-dev mailing list
>>>>> cdi-dev at lists.jboss.org <mailto:cdi-dev at lists.jboss.org>
>>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev <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 <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/20150318/f6cabd66/attachment-0001.html

More information about the cdi-dev mailing list