[cdi-dev] On @Observes for async events

Wed Mar 18 06:16:33 EDT 2015

Think it is highly wrong, if you need priorities between tasks in async
world you use completion hooks, sequentializing them arbitrarily just makes
it not async anymore (+ think to the case you dont really have priorities
you are just breaking the whole concept).

So a deifnitionexception is the thing to throw when you have
@Async+ at Priority IMO.

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 11:11 GMT+01:00 Antoine Sabot-Durand <antoine at sabot-durand.net>:

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