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).
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.
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.
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(a)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...
<
http://cdi-development-mailing-list.1064426.n5.nabble.com/Update-on-Async...>)
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(a)gmail.com
<mailto:rmannibucau@gmail.com>> a écrit :
>
>
> 2015-03-18 11:03 GMT+01:00 Antoine Sabot-Durand <antoine(a)sabot-durand.net
<mailto:antoine@sabot-durand.net>>:
>
>> Le 18 mars 2015 à 10:53, Romain Manni-Bucau <rmannibucau(a)gmail.com
<mailto:rmannibucau@gmail.com>> a écrit :
>>
>>
>> 2015-03-18 10:33 GMT+01:00 Antoine Sabot-Durand <antoine(a)sabot-durand.net
<mailto:antoine@sabot-durand.net>>:
>>
>>> Le 18 mars 2015 à 09:58, Romain Manni-Bucau <rmannibucau(a)gmail.com
<mailto:rmannibucau@gmail.com>> a écrit :
>>>
>>>
>>> 2015-03-18 9:55 GMT+01:00 Antoine Sabot-Durand <antoine(a)sabot-durand.net
<mailto:antoine@sabot-durand.net>>:
>>>>
>>>> Le 18 mars 2015 à 09:42, Romain Manni-Bucau <rmannibucau(a)gmail.com
<mailto:rmannibucau@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(a)openknowledge.de
<mailto:arne.limburg@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(a)sabot-durand.net
<mailto:antoine@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(a)openknowledge.de <mailto:arne.limburg@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(a)sabot-durand.net
<mailto:antoine@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(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
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.