[cdi-dev] Previously on "Double end async events activation"

Thu Mar 26 05:59:27 EDT 2015

> Le 25 mars 2015 à 20:28, Mark Paluch <mpaluch at paluch.biz> a écrit :
> 
> Hi Antoine,
> 
> thanks for your input and this summary.
> I placed my comments inline.
> 
> Best regards, Mark
> 
> 
>> Am 25.03.2015 um 14:45 schrieb Antoine Sabot-Durand <antoine at sabot-durand.net>:
>> 
>> Hi all,
>> 
>> 
>> This mail is quite long, but if you want to catch up on this double end activation for async event and bring your help on this point, you should take the 10 mn to read it and make your feedback. We’ve been talking of this for more thant on month now, so it’s normal that reflection and proposition take a few lines to synthesize
>> Discussion is going back to solution avoiding this double activation stuff for async event. To avoid explaining again why we should care and the solution we already explore here is a small wrap up of previous episodes :
>> 
>> 1) Why is it important to take time on this?
>> Some of you may find we already spend too many time on this question, but remember. Async events are the 1st requested stuff from the community. It has been asked for a long time (Jira ticket is CDI-4). We didn’t provided a solution for CDI 1.1 so now people are waiting this feature and they probably hope it’ll be nicely designed.
>> To make short : if we don’t deliver users will be very disappointed, if we propose a lousy solution people will be very critic. I know that it’s better to not deliver than delivering something we are not happy with, but we really should be careful here
> 
> +1 CDI 2.0 without async events seems a no-go
> 
>> 
>> 
>> 2) Why this double activation is needed?
>> For the producer (fire()) side it’s rather obvious : we cannot magically change all synchronous event call to async. We need an handle on the work in progress (so a new method signature with CompletionStage), the payload mutation mechanism would break as all transactional events. So there’s no debate on fireAsync()
> 
> +1 on fireAsync
> 
> fireAsync triggers always asynchronous event processing. Currently we’re talking about interference between observers, but there are lots of other ways to do nasty things (e.g. modifying the payload from the firing thread). Any caller expects a method returning CompletionStage returning instantly, before any work is done. This leads to the point that disabling async on legacy observers would lead that fireAsync would return after those legacy observers are processed.

yes, it will behave like a standard fire().

BTW the interesting part of my paragraph is "why it is needed on observer". As you seem to exclude that constraint in your following proposal, I’d like to read why you think so

> 
>> 
>> 
>> 3) Implementing this observer activation
>> 
>> I’m listing here all the solution to deal with this requirement. For some of them I’ll add the reason we won’t adopt it or my feeling about it
>> 
> 
> I would add another case which might help to clarify @Priority as well:
> 
> 1. fire with @Observers: same behavior as CDI 1.x
> 2. fireAsync with @Observes: observers are processed in any order in sequence but in a different thread

How do you deal with transactional observer or observer injecting contextual beans?

> - nothing new until now -
> 3. fireAsync with @Observers and @Concurrent (obviously not async to prevent confusion): Observers carrying @Concurrent are running concurrently to each other (that’s the double-opt in case). Observers not having @Concurrent are handled like point 2. observer methods are not allowed to to have both, @Priority and @Concurrent
> 4. fire with @Observes and @Concurrent: Ability to use fire with some level of async. The behavior on the caller side does not change, fire waits until all observer method invocations are finished
> 
> We should think also about ProcessObserverMethod. That’s the place where you can override any priority/(async|concurrent) settings and perhaps even the asyncSupported flag. This sort of opt-out is maybe sufficient. Now what happens, if asyncSupported=false and fireAsync? How about just skipping the observer?

How can you choose observer to opt out? Do you suggest a case by case approach? Won’t it be a bit complicated for standard end user to add an extension for that.

Mark, you’re describing additional interesting features for async event, but don’t react on the necessity of async support flag on observer and what would be your favorite choice.

>> 
>> 4) What about changing default behavior for the local jar?
>> 
>> Idea launched by some of us. We could extend the chosen scenario by activating AsyncSupport by default on all observer on the current jar (BDA). Since the main backward compatibility issue is linked to have different CDI jar from different owners and version we could give local control to the user for his own code and jars.
>> That could be done in beans.xml like we did for bean-discovery with an async-event attributes for instance or in code by a config annotation or event in extension (but we probably should expose the BDA concept in SPI if we go that way…)
> 
> This feels like a dirty hack and in the end you can’t tell how your application will behave.

It’s like your ProcessObserverMethod solution but limited to one Bean Archive that user controls. It’s only a convenient way to replace async opt-in addition on 99 observer by one opt-out on 1 observer…

> 
>> 
>> 5)Conclusion:
>> Now you have the whole picture. If I missed things, tell me. If you like an idea please tell it, if you have a new idea or a different POV, feel free to speak.
>> 
>> Thanks for reading.
>> 
>> 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.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 495 bytes
Desc: Message signed with OpenPGP using GPGMail
Url : http://lists.jboss.org/pipermail/cdi-dev/attachments/20150326/aaca47d7/attachment-0001.bin 