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

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 >

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)

that said if we have @Async methods I think async observers are really useless, isn't it?

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 <mailto:arne.limburg@openknowledge.de>>: 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 <mailto:antoine@sabot-durand.net>>: >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 <mailto:arne.limburg@openknowledge.de>> 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 <mailto:antoine@sabot-durand.net>>: >> >>> 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 <mailto:cdi-dev@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.

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 <mailto:antoine@sabot-durand.net>>: > > Le 18 mars 2015 à 09:42, Romain Manni-Bucau <rmannibucau(a)gmail.com <mailto:rmannibucau@gmail.com>> 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.

That said saying a method is async is still more elegant than firing it in a pool you don't control.

> > > > 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 <mailto:arne.limburg@openknowledge.de>>: > 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 <mailto:antoine@sabot-durand.net>>: > > >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 <mailto:arne.limburg@openknowledge.de>> 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 <mailto:antoine@sabot-durand.net>>: > >> > >>> 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 <mailto:cdi-dev@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. >

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 <mailto:antoine@sabot-durand.net>>: > Le 18 mars 2015 à 09:58, Romain Manni-Bucau <rmannibucau(a)gmail.com <mailto:rmannibucau@gmail.com>> a écrit : > > > 2015-03-18 9:55 GMT+01:00 Antoine Sabot-Durand <antoine(a)sabot-durand.net <mailto:antoine@sabot-durand.net>>: >> >> Le 18 mars 2015 à 09:42, Romain Manni-Bucau <rmannibucau(a)gmail.com <mailto:rmannibucau@gmail.com>> 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.

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

> >> >> >> >> 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 <mailto:arne.limburg@openknowledge.de>>: >> 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 <mailto:antoine@sabot-durand.net>>: >> >> >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 <mailto:arne.limburg@openknowledge.de>> 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 <mailto:antoine@sabot-durand.net>>: >> >> >> >>> 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 <mailto:cdi-dev@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. >> > >

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 <mailto:antoine@sabot-durand.net>>: > Le 18 mars 2015 à 10:53, Romain Manni-Bucau <rmannibucau(a)gmail.com <mailto:rmannibucau@gmail.com>> a écrit : > > > 2015-03-18 10:33 GMT+01:00 Antoine Sabot-Durand <antoine(a)sabot-durand.net <mailto:antoine@sabot-durand.net>>: > >> Le 18 mars 2015 à 09:58, Romain Manni-Bucau <rmannibucau(a)gmail.com <mailto:rmannibucau@gmail.com>> a écrit : >> >> >> 2015-03-18 9:55 GMT+01:00 Antoine Sabot-Durand <antoine(a)sabot-durand.net <mailto:antoine@sabot-durand.net>>: >>> >>> Le 18 mars 2015 à 09:42, Romain Manni-Bucau <rmannibucau(a)gmail.com <mailto:rmannibucau@gmail.com>> 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 <mailto:arne.limburg@openknowledge.de>>: >>> 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 <mailto:antoine@sabot-durand.net>>: >>> >>> >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 <mailto:arne.limburg@openknowledge.de>> 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 <mailto:antoine@sabot-durand.net>>: >>> >> >>> >>> 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 <mailto:cdi-dev@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.

sequentializing them arbitrarily just makes it not async anymore

(+ think to the case you dont really have priorities you are just breaking the whole concept).

2015-03-18 13:15 GMT+01:00 Jozef Hartinger <jharting(a)redhat.com <mailto:jharting@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.

(+ 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)

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.

2015-03-18 13:35 GMT+01:00 Jozef Hartinger <jharting(a)redhat.com <mailto:jharting@redhat.com>>: 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 > <mailto:jharting@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

> > (+ 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

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

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 <mailto:jharting@redhat.com>>: 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 <mailto:jharting@redhat.com>>: > > 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 <mailto:jharting@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.

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.

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 <mailto:pmuir@redhat.com>> a écrit : > > >> On 18 Mar 2015, at 13:04, Romain Manni-Bucau <rmannibucau(a)gmail.com <mailto:rmannibucau@gmail.com>> wrote: >> >> >> 2015-03-18 13:55 GMT+01:00 Jozef Hartinger <jharting(a)redhat.com <mailto:jharting@redhat.com>>: >> >> 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 <mailto:jharting@redhat.com>>: >>> >>> 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 <mailto:jharting@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(a)lists.jboss.org <mailto:cdi-dev@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(a)lists.jboss.org <mailto:cdi-dev@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.

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 <mailto:pmuir@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().

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.

> >> On 18 Mar 2015, at 15:36, Antoine Sabot-Durand <antoine(a)sabot-durand.net <mailto:antoine@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(a)redhat.com <mailto:pmuir@redhat.com>> a écrit : >>> >>> >>>> On 18 Mar 2015, at 13:04, Romain Manni-Bucau <rmannibucau(a)gmail.com <mailto:rmannibucau@gmail.com>> wrote: >>>> >>>> >>>> 2015-03-18 13:55 GMT+01:00 Jozef Hartinger <jharting(a)redhat.com <mailto:jharting@redhat.com>>: >>>> >>>> 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 <mailto:jharting@redhat.com>>: >>>>> >>>>> 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 <mailto:jharting@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(a)lists.jboss.org <mailto:cdi-dev@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(a)lists.jboss.org <mailto:cdi-dev@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. >> >

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 <mailto:pmuir@redhat.com>>: > On 18 Mar 2015, at 16:46, Antoine Sabot-Durand <antoine(a)sabot-durand.net <mailto:antoine@sabot-durand.net>> wrote: > > >> Le 18 mars 2015 à 17:31, Pete Muir <pmuir(a)redhat.com <mailto:pmuir@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

and other EE parts?

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 <mailto:antoine@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(a)redhat.com <mailto:pmuir@redhat.com>> a écrit : >>>> >>>> >>>>> On 18 Mar 2015, at 13:04, Romain Manni-Bucau <rmannibucau(a)gmail.com <mailto:rmannibucau@gmail.com>> wrote: >>>>> >>>>> >>>>> 2015-03-18 13:55 GMT+01:00 Jozef Hartinger <jharting(a)redhat.com <mailto:jharting@redhat.com>>: >>>>> >>>>> 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 <mailto:jharting@redhat.com>>: >>>>>> >>>>>> 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 <mailto:jharting@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(a)lists.jboss.org <mailto:cdi-dev@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(a)lists.jboss.org <mailto:cdi-dev@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.

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 <mailto:pmuir@redhat.com>>: > On 18 Mar 2015, at 17:26, Romain Manni-Bucau <rmannibucau(a)gmail.com <mailto:rmannibucau@gmail.com>> wrote: > > > > 2015-03-18 17:57 GMT+01:00 Pete Muir <pmuir(a)redhat.com <mailto:pmuir@redhat.com>>: > >> On 18 Mar 2015, at 16:46, Antoine Sabot-Durand <antoine(a)sabot-durand.net <mailto:antoine@sabot-durand.net>> wrote: >> >> >>> Le 18 mars 2015 à 17:31, Pete Muir <pmuir(a)redhat.com <mailto:pmuir@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. 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 <mailto:antoine@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(a)redhat.com <mailto:pmuir@redhat.com>> a écrit : >>>>> >>>>> >>>>>> On 18 Mar 2015, at 13:04, Romain Manni-Bucau <rmannibucau(a)gmail.com <mailto:rmannibucau@gmail.com>> wrote: >>>>>> >>>>>> >>>>>> 2015-03-18 13:55 GMT+01:00 Jozef Hartinger <jharting(a)redhat.com <mailto:jharting@redhat.com>>: >>>>>> >>>>>> 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 <mailto:jharting@redhat.com>>: >>>>>>> >>>>>>> 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 <mailto:jharting@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(a)lists.jboss.org <mailto:cdi-dev@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(a)lists.jboss.org <mailto:cdi-dev@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.

On 18 Mar 2015, at 17:56, Romain Manni-Bucau <rmannibucau(a)gmail.com&gt; wrote: request scope in CDI means thread scope = thread safe. If you assume it and propagate it in another threa (async) then you can be no more thread safe. if observers rely on request beans (logged user?) then app is broken 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 18:42 GMT+01:00 Pete Muir <pmuir(a)redhat.com <mailto:pmuir@redhat.com>>: Care to be a little less vague? ;-) > On 18 Mar 2015, at 17:40, Romain Manni-Bucau <rmannibucau(a)gmail.com <mailto:rmannibucau@gmail.com>> wrote: > > > 2015-03-18 18:30 GMT+01:00 Pete Muir <pmuir(a)redhat.com <mailto:pmuir@redhat.com>>: > >> On 18 Mar 2015, at 17:26, Romain Manni-Bucau <rmannibucau(a)gmail.com <mailto:rmannibucau@gmail.com>> wrote: >> >> >> >> 2015-03-18 17:57 GMT+01:00 Pete Muir <pmuir(a)redhat.com <mailto:pmuir@redhat.com>>: >> >>> On 18 Mar 2015, at 16:46, Antoine Sabot-Durand <antoine(a)sabot-durand.net <mailto:antoine@sabot-durand.net>> wrote: >>> >>> >>>> Le 18 mars 2015 à 17:31, Pete Muir <pmuir(a)redhat.com <mailto:pmuir@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. > > > 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 <mailto:antoine@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(a)redhat.com <mailto:pmuir@redhat.com>> a écrit : >>>>>> >>>>>> >>>>>>> On 18 Mar 2015, at 13:04, Romain Manni-Bucau <rmannibucau(a)gmail.com <mailto:rmannibucau@gmail.com>> wrote: >>>>>>> >>>>>>> >>>>>>> 2015-03-18 13:55 GMT+01:00 Jozef Hartinger <jharting(a)redhat.com <mailto:jharting@redhat.com>>: >>>>>>> >>>>>>> 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 <mailto:jharting@redhat.com>>: >>>>>>>> >>>>>>>> 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 <mailto:jharting@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(a)lists.jboss.org <mailto:cdi-dev@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(a)lists.jboss.org <mailto:cdi-dev@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.

On 19 Mar 2015, at 06:25, Mark Struberg <struberg(a)yahoo.de&gt; wrote: >> but opposed to ee concurrency utilities > > I thought this was by mistake rather than design? As far as I remember there was a long discussion on the EJB EG and it was intentionally that @Asynchronous does NOT propagate any information about the session, security, and don’t even share the same pool instance from @Stateless (pool ~what we have as @RequestScoped). The reason is that EJB is all about removing concurrency complexity from the user as good as possible. The other problem is that you don’t have it under control how long the new thread will run. And the Session might be looong time dead already. Another issue is with TX handling. The JPA spec and also JTA spec (TransactionSynchronizationRegistry) defines that a transaction must not be used ‚concurrently‘. Means they only must be assigned to a very single Thread. Even with servlet 3.0 async requests you have a ServletRequest only attached to a very single thread AT EACH TIME (means the thread might switch, but it’s max 1 at a time). LieGrue, strub

Slightly off topic perhaps, but @Stateless is difficult to map to a (CDI) scope. Everytime a method is called on a proxy, a different actual bean instance can be used

Am 19.03.2015 um 19:14 schrieb arjan tijms <arjan.tijms(a)gmail.com&gt;: Hi On Thursday, March 19, 2015, Mark Struberg <struberg(a)yahoo.de&gt; wrote: >> but opposed to ee concurrency utilities > > I thought this was by mistake rather than design? As far as I remember there was a long discussion on the EJB EG and it was intentionally that @Asynchronous does NOT propagate any information about the session, security, and don’t even share the same pool instance from @Stateless (pool ~what we have as @RequestScoped). Slightly off topic perhaps, but @Stateless is difficult to map to a (CDI) scope. Everytime a method is called on a proxy, a different actual bean instance can be used (but it can also be the same bean instance as used for the previous call from the same thread) The concept is actually not that far removed from a message passing paradigm, but using synchronous communication and a typed target. Kind regards, Arjan Tijms The reason is that EJB is all about removing concurrency complexity from the user as good as possible. The other problem is that you don’t have it under control how long the new thread will run. And the Session might be looong time dead already. Another issue is with TX handling. The JPA spec and also JTA spec (TransactionSynchronizationRegistry) defines that a transaction must not be used ‚concurrently‘. Means they only must be assigned to a very single Thread. Even with servlet 3.0 async requests you have a ServletRequest only attached to a very single thread AT EACH TIME (means the thread might switch, but it’s max 1 at a time). LieGrue, strub _______________________________________________ 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.

I agree with you if you look from a implementation point of view. However I believe that most @Stateless EJBs can easily be migrated to @ApplicationScoped. (At least this is what we have been doing in our migration projects until now).

Most @Stateless EJBs are implemented thread-safe unless someone violated the Stateless EJB contract;).

Jens Am 19/03/15 20:34 schrieb "Mark Struberg" unter <struberg(a)yahoo.de&gt;: >> Slightly off topic perhaps, but @Stateless is difficult to map to a >>(CDI) scope. Everytime a method is called on a proxy, a different actual >>bean instance can be used > >That is EXACTLY as NormalScoped beans are handled. Just think of >@Stateless as a @PoolScoped CDI bean. And then you are almost there… > >It’s basically @RequestScoped with re-using instances by putting them >back into a poll cache (like we had it with JSP tags in the old days). >And of course with a few default Interceptors. But that’s really it. > >LieGrue, >strub > > >> Am 19.03.2015 um 19:14 schrieb arjan tijms <arjan.tijms(a)gmail.com&gt;: >> >> Hi >> >> On Thursday, March 19, 2015, Mark Struberg <struberg(a)yahoo.de&gt; wrote: >> >> but opposed to ee concurrency utilities >> > >> > I thought this was by mistake rather than design? >> >> >> >> As far as I remember there was a long discussion on the EJB EG and it >>was intentionally that @Asynchronous does NOT propagate any information >>about the session, security, and don’t even share the same pool instance >>from @Stateless (pool ~what we have as @RequestScoped). >> >> Slightly off topic perhaps, but @Stateless is difficult to map to a >>(CDI) scope. Everytime a method is called on a proxy, a different actual >>bean instance can be used (but it can also be the same bean instance as >>used for the previous call from the same thread) >> >> The concept is actually not that far removed from a message passing >>paradigm, but using synchronous communication and a typed target. >> >> Kind regards, >> Arjan Tijms >> >> >> >> The reason is that EJB is all about removing concurrency complexity >>from the user as good as possible. The other problem is that you don’t >>have it under control how long the new thread will run. And the Session >>might be looong time dead already. Another issue is with TX handling. >>The JPA spec and also JTA spec (TransactionSynchronizationRegistry) >>defines that a transaction must not be used ‚concurrently‘. Means they >>only must be assigned to a very single Thread. >> >> Even with servlet 3.0 async requests you have a ServletRequest only >>attached to a very single thread AT EACH TIME (means the thread might >>switch, but it’s max 1 at a time). >> >> >> >> LieGrue, >> strub >> _______________________________________________ >> 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 &gt;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.

I don't really agree. @RequestScoped will give you the same bean as long as the same request scope is active for the caller. Every call is guaranteed to go to the same bean.

For @Stateless the situation is actually reversed. There is no scope that the caller is in. Every call the caller makes on a bean may go to a difference instance. Conceptually it's like a method call results in a package containing the call details being put on a queue, then a *random* bean is chosen from a pool or created on the spot to process that package. Then when it finishes processing the result is returned to the caller and that random bean is put back into the pool or is immediately destroyed. That’s IMHO really nothing like @RequestScoped. @PoolScoped is tempting, but not possible the way the EJB spec is defined now. The reason is simply that there’s nothing in the spec that mandates stateless beans to be pooled.

At any length, @PoolScoped would define the life-time of a bean (when it’s constructed and when it's destroyed) indeed, but it would mean nothing for the caller.

On 18 Mar 2015, at 10:11, Antoine Sabot-Durand <antoine(a)sabot-durand.net&gt; wrote: 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... <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 <mailto:rmannibucau@gmail.com>> a écrit : > > > 2015-03-18 11:03 GMT+01:00 Antoine Sabot-Durand <antoine(a)sabot-durand.net <mailto:antoine@sabot-durand.net>>: > >> Le 18 mars 2015 à 10:53, Romain Manni-Bucau <rmannibucau(a)gmail.com <mailto:rmannibucau@gmail.com>> a écrit : >> >> >> 2015-03-18 10:33 GMT+01:00 Antoine Sabot-Durand <antoine(a)sabot-durand.net <mailto:antoine@sabot-durand.net>>: >> >>> Le 18 mars 2015 à 09:58, Romain Manni-Bucau <rmannibucau(a)gmail.com <mailto:rmannibucau@gmail.com>> a écrit : >>> >>> >>> 2015-03-18 9:55 GMT+01:00 Antoine Sabot-Durand <antoine(a)sabot-durand.net <mailto:antoine@sabot-durand.net>>: >>>> >>>> Le 18 mars 2015 à 09:42, Romain Manni-Bucau <rmannibucau(a)gmail.com <mailto:rmannibucau@gmail.com>> 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 <mailto:arne.limburg@openknowledge.de>>: >>>> 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 <mailto:antoine@sabot-durand.net>>: >>>> >>>> >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 <mailto:arne.limburg@openknowledge.de>> 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 <mailto:antoine@sabot-durand.net>>: >>>> >> >>>> >>> 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 <mailto:cdi-dev@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(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.

On 03/18/2015 04:14 PM, Pete Muir wrote: I think I have misunderstood the async model that is being proposed. We are proposing that all the observers of an event fired asynchronously are all run on a single thread? (Not the thread that fires the event, another thread, but the same thread for each observer). No, the current proposal is not that specific at this point do define a particular architecture. The one you mentioned is one of the possible options. It has certain advantages: - the caller of fireAsync() does not wait for observers to complete so it is async for the caller - observer notification works the same as way as we know today except that in a different thread - the common pattern of using mutable event payload on which observers contribute would work fine - the payload does not need to be thread-safe - it would be safely published to the notification thread by the CDI implementation and there are no races between observers - ordering (if needed) fits well Disadvantages - it does not eliminate the backward-compatibility problem completely (different thread means different transaction context, CDI contexts and thread locals) - observers are not called in parallel Another option would be to call the observers in parallel Advantages: - the caller of fireAsync() does not wait for observers to complete so it is async for the caller - observers are independent of each other Disadvantages: - it does not eliminate the backward-compatibility problem completely (different thread means different transaction context, CDI contexts and thread locals) - the payload needs to be thread-safe - ordering would not work here - single event firing possibly results in multiple exceptions (tricky for the caller to handle with CompletionStage API) Another option is to combine those two and by default call the observers in parallel. If for some reason an observer depends on a different observer (by means of priorities) then the container guarantees that the partial ordering of observer notification is met. Advantages: - the caller of fireAsync() does not wait for observers to complete so it is async for the caller - observers are independent of each other - priority works the same in sync and async Disadvantages: - it does not eliminate the backward-compatibility problem completely (different thread means different transaction context, CDI contexts and thread locals) - the payload needs to be thread-safe - single event firing possibly results in multiple exceptions (tricky for the caller to handle with CompletionStage API) This would be a somewhat odd limitation in my mind. It’s certainly *not* something that is semantically intuitive if you have something like @Observes @Asynchronously on event observers, which definitely implies the event observation is asynchronous, not the event firing. In the current proposal, @Observes @Asynchronously is just an enabler (for backward compatibility) of async event firing. It alone does not mean anything. I would definitely prefer an asynchronous observation model, which I can’t see as being remotely compatible with observer ordering. The classic approach of using callbacks to identify when a method is done is inherently more powerful, and better understood. So basically kind of EJB's @Asynchronous methods applied to observers + a callback on event.fire()? The downside I can see here is that the event.fire() caller never knows whether the call will block or not whereas with event.fireAsync() it would be guaranteed not to block. Perhaps I’ve missed this, but what are the use cases for wanting to specify that the observation is done async on the observer? And how does this relate to the event firing methods ability to get a callback? I suspect you would need to retrofit the entire firing system to always return a callback if you wanted to allow the observer to control whether it was async or not. On 18 Mar 2015, at 10:11, Antoine Sabot-Durand <antoine(a)sabot-durand.net&gt; wrote: 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&gt;: > >> >> 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&gt;: >> >>> >>> 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. >>>> >>> _______________________________________________ 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 listcdi-dev@lists.jboss.orghttps://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.