On 18 Mar 2015, at 17:26, Romain Manni-Bucau
<rmannibucau(a)gmail.com> wrote:
2015-03-18 17:57 GMT+01:00 Pete Muir <pmuir(a)redhat.com
<mailto:pmuir@redhat.com>>:
> On 18 Mar 2015, at 16:46, Antoine Sabot-Durand <antoine(a)sabot-durand.net
<mailto:antoine@sabot-durand.net>> wrote:
>
>
>> Le 18 mars 2015 à 17:31, Pete Muir <pmuir(a)redhat.com
<mailto:pmuir@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.
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(a)sabot-durand.net
<mailto:antoine@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(a)redhat.com
<mailto:pmuir@redhat.com>> a écrit :
>>>>
>>>>
>>>>> On 18 Mar 2015, at 13:04, Romain Manni-Bucau
<rmannibucau(a)gmail.com <mailto:rmannibucau@gmail.com>> wrote:
>>>>>
>>>>>
>>>>> 2015-03-18 13:55 GMT+01:00 Jozef Hartinger <jharting(a)redhat.com
<mailto:jharting@redhat.com>>:
>>>>>
>>>>> On 03/18/2015 01:46 PM, Romain Manni-Bucau wrote:
>>>>>>
>>>>>> 2015-03-18 13:35 GMT+01:00 Jozef Hartinger
<jharting(a)redhat.com <mailto:jharting@redhat.com>>:
>>>>>>
>>>>>> On 03/18/2015 01:28 PM, Romain Manni-Bucau wrote:
>>>>>>>
>>>>>>>
>>>>>>> 2015-03-18 13:15 GMT+01:00 Jozef Hartinger
<jharting(a)redhat.com <mailto:jharting@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(a)lists.jboss.org <mailto:cdi-dev@lists.jboss.org>
>>>>>
https://lists.jboss.org/mailman/listinfo/cdi-dev
<
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
<
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(a)lists.jboss.org <mailto:cdi-dev@lists.jboss.org>
>>>>
https://lists.jboss.org/mailman/listinfo/cdi-dev
<
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
<
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.