[cdi-dev] On @Observes for async events
Jozef Hartinger
jharting at redhat.com
Wed Mar 18 08:55:59 EDT 2015
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
> <mailto: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
>> <mailto: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.
>
>>
>> (+ 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.
>
>> 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/5cb28c06/attachment-0001.html
More information about the cdi-dev
mailing list