[cdi-dev] On @Observes for async events

Wed Mar 18 13:26:04 EDT 2015

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 and other EE parts? 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/4ac7d885/attachment.html