[cdi-dev] On @Observes for async events

Mark Struberg struberg at yahoo.de
Thu Mar 19 02:14:34 EDT 2015 

Hi Pete!


> 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). 


Imo there are 2 different notion of ’async’.
1.) means at some ‚random' other point in time
2.) means at some different thread.

The BEFORE_SUCCESS (and maybe a few others) usually are category 1.). Means they fire at some other point in time (before the transaction gets finally committed), BUT they fire on the same Thread (because they need all the TX stuff set up).


> I would assume that context propagation is a must.

This is hard, but probably doable for our own scopes. @RequestScoped could probably work. @SessionScoped is _much_ harder!
And for custom Scopes ALL bets are off anyway…

So I’d rather not force this on customers. Especially not if we need some high degree of backward compatibility.

LieGrue,
strub


> Am 18.03.2015 um 17:57 schrieb Pete Muir <pmuir at redhat.com>:
> 
> 
>> On 18 Mar 2015, at 16:46, Antoine Sabot-Durand <antoine at sabot-durand.net> wrote:
>> 
>> 
>>> Le 18 mars 2015 à 17:31, Pete Muir <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.
> 
> 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> 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> a écrit :
>>>>> 
>>>>> 
>>>>>> On 18 Mar 2015, at 13:04, Romain Manni-Bucau <rmannibucau at gmail.com> wrote:
>>>>>> 
>>>>>> 
>>>>>> 2015-03-18 13:55 GMT+01:00 Jozef Hartinger <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>:
>>>>>>> 
>>>>>>> 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>:
>>>>>>>> 
>>>>>>>> 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
>>>>>> 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.
>>>>> 
>>>>> _______________________________________________
>>>>> 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.
>>>> 
>>> 
>> 
> 
> _______________________________________________
> 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.

More information about the cdi-dev mailing list