[cdi-dev] On @Observes for async events

Romain Manni-Bucau rmannibucau at gmail.com
Wed Mar 18 06:05:01 EDT 2015 

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

More information about the cdi-dev mailing list