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

Support of ordering in async event was last discussed yesterday in this thread ( http://cdi-development-mailing-list.1064426.n5.nabble.com/Update-on-Async... ) I tend to agree with Jozef. It’s more consistent for user to allow ordering in async event as in sync. Antoine Le 18 mars 2015 à 11:05, Romain Manni-Bucau <rmannibucau(a)gmail.com&gt; a écrit : 2015-03-18 11:03 GMT+01:00 Antoine Sabot-Durand <antoine(a)sabot-durand.net&gt; : > > Le 18 mars 2015 à 10:53, Romain Manni-Bucau <rmannibucau(a)gmail.com&gt; a > écrit : > > > 2015-03-18 10:33 GMT+01:00 Antoine Sabot-Durand <antoine(a)sabot-durand.net > >: > >> >> Le 18 mars 2015 à 09:58, Romain Manni-Bucau <rmannibucau(a)gmail.com&gt; a >> écrit : >> >> >> 2015-03-18 9:55 GMT+01:00 Antoine Sabot-Durand <antoine(a)sabot-durand.net >> >: >> >>> >>> Le 18 mars 2015 à 09:42, Romain Manni-Bucau <rmannibucau(a)gmail.com&gt; a >>> écrit : >>> >>> Hi guys, >>> >>> think Mark is right and a new API (as fireAsync) would be better for >>> users for: >>> - understanding >>> - compatibility (think to custom extensions using this flag) >>> >>> >>> My point here is to avoid making CDI the EJB next by introducing @Async >>> or @Asynchronous annotation in the spec. This kind of annotation should be >>> shared by other specs and would have a better fit in concurrency utilities >>> or commons annotations spec. >>> >>> >> +1 >> >> >>> that said if we have @Async methods I think async observers are really >>> useless, isn't it? >>> >>> >>> @Async is rather useless IMO when you see how easy it is do async >>> operation with Java 8. On the other hand Async observers are a at a higher >>> level since they are called thru the Container and that the fire point must >>> know what’s going on at the other side. >>> >>> >> don't get it, observer can use j8 then to do its stuff asynchronously so >> maybe the feature if finally useless assuming you run on j8. >> >> >> And how do you make your fire point know that one of its observer will >> be asynchronous ? How do you manage event ordering (as we plan to support >> it for async event as well). I think we shouldn’t see the event bus as a >> standard method call but something more featured (think about parameter >> injection in observer methods or transactional behavior) >> >> > then this is not asynchronism and just an observer queue which is > something different IMO. > > > From user pov it’s async : "I fire an event and get the control back > right away". The impl will make an observer queue in an other thread, but > the user exp is totally different than classic fire(). > > this is discussable since it is not for 2 observers. If you use async it can be - often - cause of a long processing, if you have 2 long computing methods then you sequentiallize it which breaks the reason why you wanted async, no? > > >> >> That said saying a method is async is still more elegant than firing it >> in a pool you don't control. >> >> >> fireAsync will have a signature allowing you to pass your own Executor >> to give you better control on thread pool >> >> > a default one should be bound to the bm - main case IMO. having an app > executor is not a very nice solution in term of API. > > > Yes it was already discussed, there will be 2 signatures for fireAsync(). > > > > >> >>> >>> >>> >>> Romain Manni-Bucau >>> @rmannibucau <https://twitter.com/rmannibucau> | Blog >>> <http://rmannibucau.wordpress.com/> | Github >>> <https://github.com/rmannibucau> | LinkedIn >>> <https://www.linkedin.com/in/rmannibucau> | Tomitriber >>> <http://www.tomitribe.com/> >>> >>> 2015-03-18 9:30 GMT+01:00 Arne Limburg <arne.limburg(a)openknowledge.de&gt;: >>> >>>> Hi Antoine, >>>> >>>> The third bullet point in 10.5.1 of the CDI 1.1 spec states that the >>>> observer method must be called in the same transaction context as the >>>> event.fire(...) if it is no transactional observer (that is >>>> TransactionPhase.IN_PROGRESS). >>>> If the default behavior would be async, we would have to move the >>>> transaction context to another thread. To my best knowledge this would >>>> be >>>> the only situation in EE where this is the case. >>>> >>>> Cheers, >>>> Arne >>>> >>>> Am 18.03.15 09:21 schrieb "Antoine Sabot-Durand" unter >>>> <antoine(a)sabot-durand.net&gt;: >>>> >>>> >Hi Arne, >>>> > >>>> >Sorry can you explain why? This value allows observer to be called >>>> inside >>>> >or outside a transaction. What will be the compatibility issue? >>>> > >>>> >Antoine >>>> > >>>> > >>>> >> Le 18 mars 2015 à 09:05, Arne Limburg < >>>> arne.limburg(a)openknowledge.de&gt; a >>>> >>écrit : >>>> >> >>>> >> Hi to all, >>>> >> >>>> >> I think the biggest issue with backward compatibility is, that the >>>> >>current >>>> >> @Observes annotation by default has TransactionPhase.IN_PROGRESS. >>>> >> I think we can¹t deal with this, if the default for observers would >>>> be >>>> >> async. So I think there is no way to specify async as default >>>> without >>>> >> loosing backward compatibility. >>>> >> Any other thoughts? >>>> >> >>>> >> Cheers, >>>> >> Arne >>>> >> >>>> >> >>>> >> Am 18.03.15 08:48 schrieb "Antoine Sabot-Durand" unter >>>> >> <antoine(a)sabot-durand.net&gt;: >>>> >> >>>> >>> Hi all, >>>> >>> >>>> >>> Yesterday we had another meeting to try to find a better solution >>>> than >>>> >>> explicitly activating async event on observer, without no success. >>>> I >>>> >>> understand that we should go on on this feature so what I suggest >>>> is to >>>> >>> have a meeting (an hangout) with people that want to try to find a >>>> >>>better >>>> >>> solution. If we find something we¹ll do a last proposal, and in all >>>> >>>case >>>> >>> we¹ll adopt the woking solution next week for this point. People >>>> >>> interested with this please manifest yourself. >>>> >>> >>>> >>> If we have to go with opt-in (have to explicitly declare an >>>> observer >>>> >>> supporting async event) we also have to validate the decision to >>>> use a >>>> >>> member in @Observes (as it was decided before) or go back on that >>>> as >>>> >>> mMark keep asking by introducing a new annotation to add on the >>>> >>>observer >>>> >>> (@Async or something similar). As I said when we discussed this >>>> point, >>>> >>>I >>>> >>> prefer the member in @Observes but we may have overlooked issues >>>> linked >>>> >>> to backward compatibility. >>>> >>> A third solution might be to introduce an @ObserveAsync to declare >>>> an >>>> >>> asynchronous capable observerŠ >>>> >>> >>>> >>> I¹m waiting for active feedback from you to find the best solution >>>> >>>taking >>>> >>> ALL aspects (not only the technicals one) into account. >>>> >>> >>>> >>> Thanks, >>>> >>> >>>> >>> 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. >>>> >>>