Re: [cdi-dev] On @Observes for async events

Care to be a little less vague? ;-) On 18 Mar 2015, at 17:40, Romain Manni-Bucau <rmannibucau(a)gmail.com&gt; wrote: 2015-03-18 18:30 GMT+01:00 Pete Muir <pmuir(a)redhat.com&gt;: > > On 18 Mar 2015, at 17:26, Romain Manni-Bucau <rmannibucau(a)gmail.com&gt; > wrote: > > > > 2015-03-18 17:57 GMT+01:00 Pete Muir <pmuir(a)redhat.com&gt;: > >> >> On 18 Mar 2015, at 16:46, Antoine Sabot-Durand <antoine(a)sabot-durand.net&gt; >> wrote: >> >> >> Le 18 mars 2015 à 17:31, Pete Muir <pmuir(a)redhat.com&gt; 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. > > yes and no, propagating request scope can break the whole app > 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(a)sabot-durand.net&gt; >> 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(a)redhat.com&gt; a écrit : >> >> >> On 18 Mar 2015, at 13:04, Romain Manni-Bucau <rmannibucau(a)gmail.com&gt; >> wrote: >> >> >> 2015-03-18 13:55 GMT+01:00 Jozef Hartinger <jharting(a)redhat.com&gt;: >> >>> >>> On 03/18/2015 01:46 PM, Romain Manni-Bucau wrote: >>> >>> >>> 2015-03-18 13:35 GMT+01:00 Jozef Hartinger <jharting(a)redhat.com&gt;: >>> >>>> >>>> On 03/18/2015 01:28 PM, Romain Manni-Bucau wrote: >>>> >>>> >>>> >>>> 2015-03-18 13:15 GMT+01:00 Jozef Hartinger <jharting(a)redhat.com&gt;: >>>> >>>>> >>>>> 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(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. >> >> >> _______________________________________________ >> 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. >> >>