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

Jozef Hartinger jharting at redhat.com
Tue Feb 10 04:31:48 EST 2015 

The current proposal is for fireAsync() to never wait for completion. If 
needed, a completion callback may be registered on the 
CompletableFuture/CompletionStage-like object returned from fireAsync().

http://docs.jboss.org/weld/javadoc/3.0/weld-api/org/jboss/weld/experimental/ExperimentalEvent.html#fireAsync-U-

On 02/09/2015 08:33 PM, Mark Struberg wrote:
> 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.

More information about the cdi-dev mailing list