[cdi-dev] Async events. We need ideas to improve CDI-499

José Paumard jose.paumard at gmail.com
Tue Feb 10 02:41:15 EST 2015 

Mark,

It vas never been in the mind of anyone to modify the way things work
currently. Keeping the backward compatibility is a prerequisite to any kind
of modification or improvment added to the spec. This has already been said
and written several times.

José
Le 10 févr. 2015 07:37, "Mark Struberg" <struberg at yahoo.de> a écrit :

> Good morning!
>
>
> Folks, please think a bit further.
>
>
> I'll give you a practical example. What should a developer do first? Eat
> their own dog food...
>
> Where does this apply to us? Means where do _we_ use CDI events? Right, in
> CDI Extensions.
>
> So ask yourself a simple question: if we like to leverage async events in
> CDI extensions then how could we do that? Your suggestion was to just use
> fireAsync instead of fire, right?
>
> Now imagine what would happen if we would do that... I'd say most real
> world apps would go BOOOOMMMMM and not even finish the start. Simply
> because most CDI extensions are not built to be executed in parallel. Just
> look at Extensions who collect information about classes in @Observes
> ProcessAnnotatedType. Most of the time they collect this in a
> non-concurrent Set or List
>
> private final Collection<AnnotatedType<?>> messageBundleTypes = new
> HashSet<AnnotatedType<?>>();
>
>
> If you fire the ProcessAnnotatedType event in parallel then you will blow
> up. And this was just ONE example. There are tons of other CDI Extension
> Events which would have the same result if switched to fireAsync.
>
>
> Now think about what would happen IF we would have an @Async on the
> observer?
>
> All would work. Old extensions still will get triggered in the same
> thread, but extensions with @Async would leverage parallel behaviour.
>
>
> I hope this practical sample makes it more clear why I think that most of
> the time we cannot simply switch to fireAsync if there is old code around
> which is not under your full control.
>
>
> LieGrue,
> strub
>
>
>
>
>
>
> > On Monday, 9 February 2015, 20:56, Romain Manni-Bucau <
> rmannibucau at gmail.com> wrote:
> > > I guess 2 is not a real need - and at least not why people voted for
> > this feature. Difference between fireAsync and @Async is who decides
> > to be asynchronous. Caller (fire) should clearly be able IMO - with
> > all the warning we can put in the spec to say it should be done with
> > compatible scopes. The second one is less important for me cause you
> > can already do it with concurrency utilities (ee one or not) pretty
> > easily.
> >
> >
> > Romain Manni-Bucau
> > @rmannibucau
> > http://www.tomitribe.com
> > http://rmannibucau.wordpress.com
> > https://github.com/rmannibucau
> >
> >
> > 2015-02-09 20:33 GMT+01:00 Mark Struberg <struberg at yahoo.de>:
> >>  Btw, did we already cover the 'fireAndForget' vs
> > 'fireAndWait' use cases?
> >>
> >>  1. fireAndForget: this is basically what you get today if you use
> > @javax.ejb.Asynchronous on an @Observer method
> >>
> >>  2.) fireAndWait: call all observers in a new thread and only return
> after
> > all observer methods did finish.
> >>
> >>
> >>
> >>  Did we already agree on one of the 2 modi? If not, do we like to
> support
> > both? And if so, how to tell the CDI container which of the 2 modes to
> use for
> > each observer?
> >>
> >>
> >>  If you answer the last question with yes then we might need some
> > annotation/additional info on the observer method anyway. And then we
> are back
> > on our @Async annotation on the observer method...
> >>
> >>
> >>  LieGrue,
> >>  strub
> >>
> >>
> >>  On Monday, 9 February 2015, 18:43, Romain Manni-Bucau
> > <rmannibucau at gmail.com> wrote:
> >>> Guys I'm not sure to fully get the jira description now. Can you try
> >>> to rephrase it a bit?
> >>>
> >>> Here what I see:
> >>>
> >>> 1) fireAsync (+1) is clear
> >>> 2) (part I dont fully get) asyncSupported: is it mandatory? If yes I
> >>> think this API is not usable (=user friendly) and I would just suggest
> >>> it is on by default and to remove this flag
> >>>
> >>>
> >>> Can it break apps? Yes as mentionned by Mark. Will it break apps? No
> >>> since it is not yet used and this is surely what we want. I fully
> >>> understand all the mentionned pitfalls - but let me say @RequestScoped
> >>> is by definition as broken as this today since you can't associate
> > it
> >>> with a request for the exact same reason. What I mean is: if you
> >>> choose async then you assume it so I think we shouldn't protect the
> >>> user from pitfalls then...in particular since we can't protect him
> >>> from other as vicious issues.
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> Romain Manni-Bucau
> >>> @rmannibucau
> >>> http://www.tomitribe.com
> >>> http://rmannibucau.wordpress.com
> >>> https://github.com/rmannibucau
> >>>
> >>>
> >>> 2015-02-09 18:28 GMT+01:00 Antoine Sabot-Durand
> > <antoine at sabot-durand.net>:
> >>>>  Mark I understand your concern, now can you understand the one we
> > discussed about the fact of having to enable async at both ends is a
> source of
> > confusion for end users and will give a bad perception of the spec.
> >>>>
> >>>>  So could we figure something user friendly to enable async event?
> >>>>
> >>>>  Antoine
> >>>>
> >>>>
> >>>>>  Le 9 févr. 2015 à 12:00, Mark Struberg
> > <struberg at yahoo.de> a écrit :
> >>>>>
> >>>>>  But that might defeat pluggabilgity. Basically no framework can
> > use fireAsync in that case.
> >>>>>
> >>>>>  Imagine a UserLoggedIn event. For most observers it is
> > perfectly fine to observe this in a new thread. But some might need to
> access
> > the session -> boom. Which means that all frameworks have to fall back
> to the
> > 'safe' fire() instead of fireAsync()...
> >>>>>
> >>>>>  That will leave us half-broken as it totally defeats the usage
> > of this cool feature...
> >>>>>
> >>>>>  LieGrue,
> >>>>>  strub
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>>  On Monday, 9 February 2015, 11:51, Antoine Sabot-Durand
> > <antoine at sabot-durand.net> wrote:
> >>>>>>>  Mark,
> >>>>>>
> >>>>>>
> >>>>>>  During last meeting we didn’t say there wasn’t use case
> > that would break
> >>>>>>  existing observer, we said that since we keep the current
> > fire() method there is
> >>>>>>  backward compatibility. User trying to send fireAsync() and
> > experiencing error
> >>>>>>  with legacy observer will have to fall back to fire().
> >>>>>>
> >>>>>>  Antoine
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>>  Le 9 févr. 2015 à 11:12, Mark Struberg
> > <struberg at yahoo.de> a écrit :
> >>>>>>>
> >>>>>>>  Hi Jozef, here we go!
> >>>>>>>
> >>>>>>>
> >>>>>>>  1.) accessing @RequestScoped beans in your Observer
> >>>>>>>
> >>>>>>>  2.) accessing @SessionScoped beans in your Observer
> >>>>>>>  3.) accessing/relying on any transactional behaviour.
> > This is really a
> >>>>>>  boomer. Basically you break transactions that way.
> >>>>>>>
> >>>>>>>  4.) accessing @TransactionScoped beans in your Observer
> >>>>>>>
> >>>>>>>  5.) access/relying on any ThreadLocal in your Observer
> >>>>>>>  6.) accessing attached entities in your Observers (they
> > must only get
> >>>>>>  accessed from a very single Thread according to the JPA
> > spec)
> >>>>>>>  7.) using an EntityManager in a parallel thread might
> > give you unexpected
> >>>>>>  results.
> >>>>>>>
> >>>>>>>
> >>>>>>>  There might be quite a few more. E.g. we need to
> > specify that EJBs and
> >>>>>>  other EE features need to work in such a new Thread, etc
> >>>>>>>
> >>>>>>>
> >>>>>>>  LieGrue,
> >>>>>>>  strub
> >>>>>>>
> >>>>>>>
> >>>>>>>  On Tuesday, 3 February 2015, 9:40, Jozef Hartinger
> >>>>>>  <jharting at redhat.com> wrote:
> >>>>>>>
> >>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>  We should enumerate all the arguments supporting
> > async flag on an
> >>>>>>  observer. So far I have only seen one:
> >>>>>>>>
> >>>>>>>>  - an observer accessing @RequestScoped state would
> > no longer be able
> >>>>>>>     to do so since it would be run in a worker thread
> >>>>>>>>
> >>>>>>>>  I am eager to hear more arguments as this single
> > one may not be
> >>>>>>>     enough to justify the observer-async-flag design
> > decision.
> >>>>>>>>
> >>>>>>>>  Remember that introducing fireAsync() itself does
> > not break any
> >>>>>>>     existing application because existing applications
> > are using fire().
> >>>>>>>     It's when an existing application / library is
> > modified to use
> >>>>>>>     fireAsync() when the problem may occur. Such change
> > should not be
> >>>>>>>     done blindly. As with any other change, an author
> > should consider
> >>>>>>>     possible consequences of the change. Clearly
> > documenting the fact
> >>>>>>>     that fireAsync() processing is done in a different
> > thread with a
> >>>>>>>     different @RequestScoped state may be sufficient.
> >>>>>>>>
> >>>>>>>>  Jozef
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>  On 02/02/2015 03:43 PM, Antoine Sabot-Durand wrote:
> >>>>>>>>
> >>>>>>>>  Hi all,
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>  https://issues.jboss.org/browse/CDI-499 comes
> > after a lot of
> >>>>>>  discussion about async events.
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>  I think the solution exposed here is quite
> > satisfying, yet the idea
> >>>>>>  to need to activate async behaviour on the observer side
> > doesn’t please a lot of
> >>>>>>  us. It’ll be confusing for users to have to activate async
> > from the firing end
> >>>>>>  and consuming end to see it work :-(.
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>  I’d like to see alternative proposal to have
> > this new feature as
> >>>>>>  user friendly as possible and keep the retro-compatibility
> > aspect.  We should
> >>>>>>  find a better solution on our next meeting on wednesday.
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>  Antoine
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>  _______________________________________________
> >>>>>>>  cdi-dev mailing list cdi-dev at lists.jboss.org
> >>>>>>  https://lists.jboss.org/mailman/listinfo/cdi-dev Note that
> > for all code provided
> >>>>>>  on this list, the provider licenses the code under the
> > Apache License, Version 2
> >>>>>>  (http://www.apache.org/licenses/LICENSE-2.0.html). For all
> > other ideas provided
> >>>>>>  on this list, the provider waives all patent and other
> > intellectual property
> >>>>>>  rights inherent in such information.
> >
> >>>
> >>>>>>>>
> >>>>>>>>  _______________________________________________
> >>>>>>>>  cdi-dev mailing list
> >>>>>>>>  cdi-dev at lists.jboss.org
> >>>>>>>>  https://lists.jboss.org/mailman/listinfo/cdi-dev
> >>>>>>>>
> >>>>>>>>  Note that for all code provided on this list, the
> > provider licenses the
> >>>>>>  code under the Apache License, Version 2
> >>>>>>  (http://www.apache.org/licenses/LICENSE-2.0.html). For all
> > other ideas provided
> >>>>>>  on this list, the provider waives all patent and other
> > intellectual property
> >>>>>>  rights inherent in such information.
> >>>>>>>>
> >>>>>>>>
> >>>>>>
> >>>>
> >>>>
> >>>>  _______________________________________________
> >>>>  cdi-dev mailing list
> >>>>  cdi-dev at lists.jboss.org
> >>>>  https://lists.jboss.org/mailman/listinfo/cdi-dev
> >>>>
> >>>>  Note that for all code provided on this list, the provider licenses
> > the code under the Apache License, Version 2
> > (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas
> provided
> > on this list, the provider waives all patent and other intellectual
> property
> > rights inherent in such information.
> >>>
> >>>
> >>
> >>  _______________________________________________
> >>  cdi-dev mailing list
> >>  cdi-dev at lists.jboss.org
> >>  https://lists.jboss.org/mailman/listinfo/cdi-dev
> >>
> >>  Note that for all code provided on this list, the provider licenses the
> > code under the Apache License, Version 2
> > (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas
> provided
> > on this list, the provider waives all patent and other intellectual
> property
> > rights inherent in such information.
> >
>
> _______________________________________________
> cdi-dev mailing list
> cdi-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/cdi-dev
>
> Note that for all code provided on this list, the provider licenses the
> code under the Apache License, Version 2 (
> http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas
> provided on this list, the provider waives all patent and other
> intellectual property rights inherent in such information.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150210/d76cf9ea/attachment-0001.html

More information about the cdi-dev mailing list