[cdi-dev] On @Observes for async events

Wed Mar 18 13:40:16 EDT 2015

2015-03-18 18:30 GMT+01:00 Pete Muir <pmuir at redhat.com>:

>
> On 18 Mar 2015, at 17:26, Romain Manni-Bucau <rmannibucau at gmail.com>
> wrote:
>
>
>
> 2015-03-18 17:57 GMT+01:00 Pete Muir <pmuir at redhat.com>:
>
>>
>> On 18 Mar 2015, at 16:46, Antoine Sabot-Durand <antoine at sabot-durand.net>
>> wrote:
>>
>>
>> Le 18 mars 2015 à 17:31, Pete Muir <pmuir at 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 at 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 at redhat.com> a écrit :
>>
>>
>> On 18 Mar 2015, at 13:04, Romain Manni-Bucau <rmannibucau at gmail.com>
>> wrote:
>>
>>
>> 2015-03-18 13:55 GMT+01:00 Jozef Hartinger <jharting at redhat.com>:
>>
>>>
>>> On 03/18/2015 01:46 PM, Romain Manni-Bucau wrote:
>>>
>>>
>>> 2015-03-18 13:35 GMT+01:00 Jozef Hartinger <jharting at redhat.com>:
>>>
>>>>
>>>> On 03/18/2015 01:28 PM, Romain Manni-Bucau wrote:
>>>>
>>>>
>>>>
>>>> 2015-03-18 13:15 GMT+01:00 Jozef Hartinger <jharting at 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 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/20150318/88615195/attachment.html