[cdi-dev] On @Observes for async events

Romain Manni-Bucau rmannibucau at gmail.com
Wed Mar 18 09:04:32 EDT 2015


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.
>
>
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.
>>
>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150318/feda5cbb/attachment.html 


More information about the cdi-dev mailing list