[cdi-dev] On @Observes for async events

José Paumard jose.paumard at gmail.com
Thu Mar 19 09:26:56 EDT 2015 

A few points :

The current fireAsync() method that has been voted for allows all this :
- calling of the observers in one different thread : just call
fireAsycn(payload, singleThreadExecutorService) and you're done
- calling of the observers "in parallel" (I dont like this way of saying
it, since it leads to confusion) is also possible by not passing any ES, or
a more than one threaded ES
In both cases you can order events in a strict (call the events of priority
N, wait for them to return, then call the next priotiry) or relax mode
(call the events of priority N, then call the events of next priority
without waiting for them to return).
There are two kinds of problems that need to be dealt with :
- fixing the 1.2 specification that does not say anything about thread /
event firing / observation (there's a JIRA for that)
- state that you need to guarantee non-race conditions on mutable event
payload in the case of concurrent observers, the easiest way (of course not
the only one) being : provide immutable payload
- context propagation through threads : we really need to work on this
point and find a clean way to do this, at least for non TX contexts (since
TX cant be accessed concurrently for other reasons).

José


2015-03-19 13:09 GMT+01:00 Jozef Hartinger <jharting at redhat.com>:

>
> On 03/18/2015 04:14 PM, Pete Muir wrote:
>
> I think I have misunderstood the async model that is being proposed. We
> are proposing that all the observers of an event fired asynchronously are
> all run on a single thread? (Not the thread that fires the event, another
> thread, but the same thread for each observer).
>
> No, the current proposal is not that specific at this point do define a
> particular architecture. The one you mentioned is one of the possible
> options.
>
> It has certain advantages:
> - the caller of fireAsync() does not wait for observers to complete so it
> is async for the caller
> - observer notification works the same as way as we know today except that
> in a different thread
> - the common pattern of using mutable event payload on which observers
> contribute would work fine - the payload does not need to be thread-safe -
> it would be safely published to the notification thread by the CDI
> implementation and there are no races between observers
> - ordering (if needed) fits well
>
> Disadvantages
> - it does not eliminate the backward-compatibility problem completely
> (different thread means different transaction context, CDI contexts and
> thread locals)
> - observers are not called in parallel
>
> Another option would be to call the observers in parallel
> Advantages:
> - the caller of fireAsync() does not wait for observers to complete so it
> is async for the caller
> - observers are independent of each other
> Disadvantages:
> - it does not eliminate the backward-compatibility problem completely
> (different thread means different transaction context, CDI contexts and
> thread locals)
> - the payload needs to be thread-safe
> - ordering would not work here
> - single event firing possibly results in multiple exceptions (tricky for
> the caller to handle with CompletionStage API)
>
> Another option is to combine those two and by default call the observers
> in parallel. If for some reason an observer depends on a different observer
> (by means of priorities) then the container guarantees that the partial
> ordering of observer notification is met.
>
> Advantages:
> - the caller of fireAsync() does not wait for observers to complete so it
> is async for the caller
> - observers are independent of each other
> - priority works the same in sync and async
> Disadvantages:
> - it does not eliminate the backward-compatibility problem completely
> (different thread means different transaction context, CDI contexts and
> thread locals)
> - the payload needs to be thread-safe
> - single event firing possibly results in multiple exceptions (tricky for
> the caller to handle with CompletionStage API)
>
>
>
>  This would be a somewhat odd limitation in my mind. It’s certainly *not*
> something that is semantically intuitive if you have something like
> @Observes @Asynchronously on event observers, which definitely implies the
> event observation is asynchronous, not the event firing.
>
> In the current proposal, @Observes @Asynchronously is just an enabler (for
> backward compatibility) of async event firing. It alone does not mean
> anything.
>
>
>  I would definitely prefer an asynchronous observation model, which I
> can’t see as being remotely compatible with observer ordering. The classic
> approach of using callbacks to identify when a method is done is inherently
> more powerful, and better understood.
>
> So basically kind of EJB's @Asynchronous methods applied to observers + a
> callback on event.fire()? The downside I can see here is that the
> event.fire() caller never knows whether the call will block or not whereas
> with event.fireAsync() it would be guaranteed not to block.
>
>
>  Perhaps I’ve missed this, but what are the use cases for wanting to
> specify that the observation is done async on the observer? And how does
> this relate to the event firing methods ability to get a callback? I
> suspect you would need to retrofit the entire firing system to always
> return a callback if you wanted to allow the observer to control whether it
> was async or not.
>
>  On 18 Mar 2015, at 10:11, Antoine Sabot-Durand <antoine at sabot-durand.net>
> wrote:
>
>  Support of ordering in async event was last discussed  yesterday in this
> thread (
> http://cdi-development-mailing-list.1064426.n5.nabble.com/Update-on-Async-event-doc-td5711176.html
> )
> I tend to agree with Jozef. It’s more consistent for user to allow
> ordering in async event as in sync.
>
>  Antoine
>
>
>  Le 18 mars 2015 à 11:05, Romain Manni-Bucau <rmannibucau at gmail.com> a
> écrit :
>
>
> 2015-03-18 11:03 GMT+01:00 Antoine Sabot-Durand <antoine at sabot-durand.net>
> :
>
>>
>>  Le 18 mars 2015 à 10:53, Romain Manni-Bucau <rmannibucau at gmail.com> a
>> écrit :
>>
>>
>>    2015-03-18 10:33 GMT+01:00 Antoine Sabot-Durand <
>> antoine at sabot-durand.net>:
>>
>>>
>>>  Le 18 mars 2015 à 09:58, Romain Manni-Bucau <rmannibucau at gmail.com> a
>>> écrit :
>>>
>>>
>>>    2015-03-18 9:55 GMT+01:00 Antoine Sabot-Durand <
>>> antoine at sabot-durand.net>:
>>>
>>>>
>>>> Le 18 mars 2015 à 09:42, Romain Manni-Bucau <rmannibucau at gmail.com> a
>>>> écrit :
>>>>
>>>>  Hi guys,
>>>>
>>>>  think Mark is right and a new API (as fireAsync) would be better for
>>>> users for:
>>>> - understanding
>>>> - compatibility (think to custom extensions using this flag)
>>>>
>>>>
>>>>  My point here is to avoid making CDI the EJB next by introducing
>>>> @Async or @Asynchronous annotation in the spec. This kind of annotation
>>>> should be shared by other specs and would have a better fit in concurrency
>>>> utilities or commons annotations spec.
>>>>
>>>>
>>>  +1
>>>
>>>
>>>>    that said if we have @Async methods I think async observers are
>>>> really useless, isn't it?
>>>>
>>>>
>>>>  @Async is rather useless IMO when you see how easy it is do async
>>>> operation with Java 8. On the other hand Async observers are a at a higher
>>>> level since they are called thru the Container and that the fire point must
>>>> know what’s going on at the other side.
>>>>
>>>>
>>>  don't get it, observer can use j8 then to do its stuff asynchronously
>>> so maybe the feature if finally useless assuming you run on j8.
>>>
>>>
>>>  And how do you make your fire point know that one of its observer will
>>> be asynchronous ? How do you manage event ordering (as we plan to support
>>> it for async event as well). I think we shouldn’t see the event bus as a
>>> standard method call but something more featured (think about parameter
>>> injection in observer methods or transactional behavior)
>>>
>>>
>>  then this is not asynchronism and just an observer queue which is
>> something different IMO.
>>
>>
>>  From user pov it’s async : "I fire an event and get the control back
>> right away". The impl will make an observer queue in an other thread, but
>> the user exp is totally different than classic fire().
>>
>>
>  this is discussable since it is not for 2 observers. If you use async it
> can be - often - cause of a long processing, if you have 2 long computing
> methods then you sequentiallize it which breaks the reason why you wanted
> async, no?
>
>>
>>
>>>
>>>  That said saying a method is async is still more elegant than firing
>>> it in a pool you don't control.
>>>
>>>
>>>  fireAsync will have a signature allowing you to pass your own Executor
>>> to give you better control on thread pool
>>>
>>>
>>  a default one should be bound to the bm - main case IMO. having an app
>> executor is not a very nice solution in term of API.
>>
>>
>>  Yes it was already discussed, there will be 2 signatures for
>> fireAsync().
>>
>>
>>
>>
>>>
>>>>
>>>>
>>>>
>>>> Romain Manni-Bucau
>>>> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
>>>> <http://rmannibucau.wordpress.com/> | Github
>>>> <https://github.com/rmannibucau> | LinkedIn
>>>> <https://www.linkedin.com/in/rmannibucau> | Tomitriber
>>>> <http://www.tomitribe.com/>
>>>>
>>>> 2015-03-18 9:30 GMT+01:00 Arne Limburg <arne.limburg at openknowledge.de>:
>>>>
>>>>> Hi Antoine,
>>>>>
>>>>> The third bullet point in 10.5.1 of the CDI 1.1 spec states that the
>>>>> observer method must be called in the same transaction context as the
>>>>> event.fire(...) if it is no transactional observer (that is
>>>>> TransactionPhase.IN_PROGRESS).
>>>>> If the default behavior would be async, we would have to move the
>>>>> transaction context to another thread. To my best knowledge this would
>>>>> be
>>>>> the only situation in EE where this is the case.
>>>>>
>>>>> Cheers,
>>>>> Arne
>>>>>
>>>>> Am 18.03.15 09:21 schrieb "Antoine Sabot-Durand" unter
>>>>>  <antoine at sabot-durand.net>:
>>>>>
>>>>> >Hi Arne,
>>>>> >
>>>>> >Sorry can you explain why? This value allows observer to be called
>>>>> inside
>>>>> >or outside a transaction. What will be the compatibility issue?
>>>>> >
>>>>> >Antoine
>>>>> >
>>>>> >
>>>>> >> Le 18 mars 2015 à 09:05, Arne Limburg <
>>>>> arne.limburg at openknowledge.de> a
>>>>> >>écrit :
>>>>> >>
>>>>> >> Hi to all,
>>>>> >>
>>>>> >> I think the biggest issue with backward compatibility is, that the
>>>>> >>current
>>>>> >> @Observes annotation by default has TransactionPhase.IN_PROGRESS.
>>>>> >> I think we can¹t deal with this, if the default for observers would
>>>>> be
>>>>> >> async. So I think there is no way to specify async as default
>>>>> without
>>>>> >> loosing backward compatibility.
>>>>> >> Any other thoughts?
>>>>> >>
>>>>> >> Cheers,
>>>>> >> Arne
>>>>> >>
>>>>> >>
>>>>> >> Am 18.03.15 08:48 schrieb "Antoine Sabot-Durand" unter
>>>>> >> <antoine at sabot-durand.net>:
>>>>> >>
>>>>> >>> Hi all,
>>>>> >>>
>>>>> >>> Yesterday we had another meeting to try to find a better solution
>>>>> than
>>>>> >>> explicitly activating async event on observer, without no success.
>>>>> I
>>>>> >>> understand that we should go on on this feature so what I suggest
>>>>> is to
>>>>> >>> have a meeting (an hangout) with people that want to try to find a
>>>>> >>>better
>>>>> >>> solution. If we find something we¹ll do a last proposal, and in all
>>>>> >>>case
>>>>> >>> we¹ll adopt the woking solution next week for this point. People
>>>>> >>> interested with this please manifest yourself.
>>>>> >>>
>>>>> >>> If we have to go with opt-in (have to explicitly declare an
>>>>> observer
>>>>> >>> supporting async event) we also have to validate the decision to
>>>>> use a
>>>>> >>> member in @Observes (as it was decided before) or go back on that
>>>>> as
>>>>> >>> mMark keep asking by introducing a new annotation to add on the
>>>>> >>>observer
>>>>> >>> (@Async or something similar). As I said when we discussed this
>>>>> point,
>>>>> >>>I
>>>>> >>> prefer the member in @Observes but we may have overlooked issues
>>>>> linked
>>>>> >>> to backward compatibility.
>>>>> >>> A third solution might be to introduce an @ObserveAsync to declare
>>>>> an
>>>>> >>> asynchronous capable observerŠ
>>>>> >>>
>>>>> >>> I¹m waiting for active feedback from you to find the best solution
>>>>> >>>taking
>>>>> >>> ALL aspects (not only the technicals one) into account.
>>>>> >>>
>>>>> >>> Thanks,
>>>>> >>>
>>>>> >>> Antoine
>>>>> >>
>>>>> >
>>>>>
>>>>>
>>>>>   _______________________________________________
>>>>> 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.
>
>
>
>
> _______________________________________________
> cdi-dev mailing listcdi-dev at lists.jboss.orghttps://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.
>



-- 
Java le soir <http://blog.paumard.org> Cours Java en ligne
<http://blog.paumard.org/cours-tutoriaux/>
Twitter <http://twitter.com/#!/JosePaumard> Paris JUG
<http://www.parisjug.org> Devoxx France <http://www.devoxx.fr>
M : +33 6 76 82 91 47
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150319/fb292aa1/attachment-0001.html

More information about the cdi-dev mailing list