[cdi-dev] Async events. We need ideas to improve CDI-499
Werner Keil
werner.keil at gmail.com
Tue Feb 10 06:12:03 EST 2015
Mark,
What do you mean by @Event?
CDI contains the Event interface, no annotation.
Are you proposing a new annotation or was it a typo?
So did you mean
@Async
private Event<UserLoggedIn> userLoggedInEventSource;
below?
Werner
On Tue, Feb 10, 2015 at 10:31 AM, <cdi-dev-request at lists.jboss.org> wrote:
> Send cdi-dev mailing list submissions to
> cdi-dev at lists.jboss.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.jboss.org/mailman/listinfo/cdi-dev
> or, via email, send a message with subject or body 'help' to
> cdi-dev-request at lists.jboss.org
>
> You can reach the person managing the list at
> cdi-dev-owner at lists.jboss.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of cdi-dev digest..."
>
>
> Today's Topics:
>
> 1. Re: Async events. We need ideas to improve CDI-499 (Mark Struberg)
> 2. Re: Async events. We need ideas to improve CDI-499 (Mark Struberg)
> 3. Re: Async events. We need ideas to improve CDI-499
> (Jozef Hartinger)
> 4. Re: Async events. We need ideas to improve CDI-499
> (Jozef Hartinger)
> 5. Re: Async events. We need ideas to improve CDI-499
> (Jozef Hartinger)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Tue, 10 Feb 2015 07:53:30 +0000 (UTC)
> From: Mark Struberg <struberg at yahoo.de>
> Subject: Re: [cdi-dev] Async events. We need ideas to improve CDI-499
> To: Jos? Paumard <jose.paumard at gmail.com>
> Cc: cdi-dev <cdi-dev at lists.jboss.org>
> Message-ID:
> <1995246191.1465726.1423554810674.JavaMail.yahoo at mail.yahoo.com>
> Content-Type: text/plain; charset=UTF-8
>
> Hi Jos?!
>
> Backward compatibility is perfectly fine with both approaches. People can
> use BeanManager#fire() instead of the newly proposed
> BeanManager#fireAsync().
>
>
> My point is that many people will simply not be able to use fireAsync()
> because as a framework developer you really need to code defensive. Without
> an explicit opt-in on observer side fireAsync() can basically only be used
> in situations where you _exactly_ know all your observers...
>
> An own @Async annotation would also be nice as it could not only be used
> at @Observes but also for @Event
>
> @Inject
> @Async
>
> @Event
>
> private Event<UserLoggedIn> userLoggedInEventSource;
>
>
> The benefit of an own @Async annotation over extending e.g. the @Event
> annotation is that it would be perfectly backward compatible. This code
> would also run on CDI-1.0 .. 1.2 containers (as all annotations which are
> not available on the classpath will simply be ignored by the JVM.
>
> LieGrue,
> strub
>
>
>
> On Tuesday, 10 February 2015, 8:41, Jos? Paumard <jose.paumard at gmail.com>
> wrote:
> >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.
> >
> >
>
> _______________________________________________
> 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.
>
> End of cdi-dev Digest, Vol 51, Issue 21
> ***************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150210/7e284175/attachment-0001.html
More information about the cdi-dev
mailing list