[cdi-dev] async: back to completion future?

Mon Mar 7 16:24:14 EST 2016

2016-03-07 22:09 GMT+01:00 Reza Rahman <reza_rahman at lycos.com>:

> Responses in-line.
>
> On Mar 7, 2016, at 3:35 PM, Romain Manni-Bucau <rmannibucau at gmail.com>
> wrote:
>
>
> 2016-03-07 20:53 GMT+01:00 Reza Rahman <reza_rahman at lycos.com>:
>
>> Yes, this can be done with a CompletableFuture that has already been
>> constructed - just take a look at the API.
>>
>>
> so - just to try to ensure we speak about the same thing:
>
> asyncEvent.fireAsync(...).thenRunAsync(() -> ..., eePool); ?
>
>
> Correct.
>
>
> This works but has the drawback to not reuse the observer thread
>
>
> Why would this matter to the average business code developer? All this
> would run from managed executors of some kind or the other anyway...
>
> and keep the original issue: the observer doesn't inherit from the caller
> context so it would likely be:
>
> asyncEvent.fireAsync(..., eePool).thenRunAsync(() -> ..., eePool);
>
>
> Again, why does it matter really?  The observer threads themselves should
> be running from a managed pool that is smart enough to preserve context
> anyway? If the business developer cares about preserving context in their
> code, they can use a managed executor themselves on the returned
> CompletableFuture.
>
>
Cause it is important to state which thread context is there to keep the
integration with other frameworks - think to security ones in particualr -
smooth and doable.

>
> which looks weird since you trigger 2 tasks where you actually want just
> one in another thread originally?
>
>
> I don't follow. Whichever executor service you would use, ultimately there
> are at least three different threads associated here in all cases.
>
>
> asyncEvent.fireAsync(..., eePool).thenRunAsync(() -> ...); // in the fire
> async thread
>
>
> You mean using the same executor? Why does this matter really? They are
> all managed executors anyway. At best it's reducing one method parameter.
>
>
Cause very few apps are 100% EE in practise, probably never will be and
even if so JavaEE security is not integrated (yet?) at this level.

> Are
> This last proposal works not that bad if context propagation would work
> but since there are cases it would be expected to work and other it
> shouldn't  - from a user point of view auto inheritance can break thread
> safety - I wonder if it shouldn't be spec-ed. Can be the new API I proposed
> or even just a new scope close to request scoped but inheritable by design.
>
>
>> As far as not adding it to CDI, I can see either way. What was the
>> original motivation for adding CompletableFutures?
>>
>> Also, it's a good idea to run this by the platform expert group. I know
>> at least JAX-RS is planning to use CompletableFutures for their client API.
>>
>> On Mar 7, 2016, at 2:39 PM, Romain Manni-Bucau <rmannibucau at gmail.com>
>> wrote:
>>
>>
>> 2016-03-07 20:35 GMT+01:00 Reza Rahman <reza_rahman at lycos.com>:
>>
>>> Talking with a colleague about this he reminded me of an important fact
>>> I almost forgot. The CompletableFuture API can actually be used with custom
>>> executors. That means users concerned about managed threads in a Java EE
>>> environment can use it with existing EE 7 concurrency executors.
>>>
>>> Basically this means CompletableFutures are already pretty Java EE ready.
>>>
>>> If this is the main cited reason for using CompletionStage, is it really
>>> that valid of an argument to justify yet another custom subclass specific
>>> only to CDI instead of what's likely to be far more familiar and expected?
>>>
>>>
>> Did he mention it is true for *created* comlpetion future which is not
>> the case for async events? But this is a good point to not add anything to
>> CDI: the feature is a one liner *already*.
>>
>>
>>> On Mar 7, 2016, at 8:11 AM, Reza Rahman <reza_rahman at lycos.com> wrote:
>>>
>>> I think this is a very bad idea. It's better not to use either API and
>>> wait to sort out how CompletableFuture can be used in EE consistently.
>>> Because of backwards compatibility rules, it is better to have no API than
>>> a bad API.
>>>
>>> On Mar 7, 2016, at 3:45 AM, Romain Manni-Bucau <rmannibucau at gmail.com>
>>> wrote:
>>>
>>> 2016-03-07 9:07 GMT+01:00 Martin Kouba <mkouba at redhat.com>:
>>>
>>>>
>>>> Dne 7.3.2016 v 09:03 Romain Manni-Bucau napsal(a):
>>>>
>>>>>
>>>>> Le 7 mars 2016 08:35, "Martin Kouba" <mkouba at redhat.com
>>>>> <mailto:mkouba at redhat.com>> a écrit :
>>>>>  >
>>>>>  > Dne 6.3.2016 v 15:39 Romain Manni-Bucau napsal(a):
>>>>>  >
>>>>>  >> Hi guys,
>>>>>  >>
>>>>>  >> as a user having a ComlpetionStage makes me loose some JDK
>>>>> utilities,
>>>>>  >> can we move back to CompletionFuture?
>>>>>  >>
>>>>>  >> It would allow for instance:
>>>>>  >>
>>>>>  >> // doesn't work with CompletionStage
>>>>>  >> CompletionFuture.allOf(event1.fireAsync(...),
>>>>> event2.fireAsync(...))
>>>>>  >>        .then(...)
>>>>>  >
>>>>>  >
>>>>>  > Well, this should work if the underlying CompletionStage impl
>>>>> supports toCompletableFuture(), i.e. in Weld 3:
>>>>>  >
>>>>>
>>>>> Yes but it is not natural to convert it IMO = we can do better
>>>>>
>>>>>  > CompletableFuture.allOf(event1.fireAsync(...).toCompletableFuture(),
>>>>> event2.fireAsync(...).toCompletableFuture())
>>>>>  >
>>>>>  > AFAIK the default async execution facility of CompletableFuture is
>>>>> ForkJoinPool.commonPool() which is not a good fit for Java EE. Using
>>>>> the
>>>>> CompletionStage interface allows us to wrap the async calls without the
>>>>> specified executor (e.g. CompletionStage.thenApplyAsync(Function<?
>>>>> super
>>>>> T, ? extends U>)) and supply a default one provided by the impl.
>>>>>  >
>>>>>
>>>>> Should use the pool in which the evznt is fired then "then step" is
>>>>> synchronous is my sample so all is decided at fire time
>>>>>
>>>>
>>>> I don't talk about your particular example - I understand that it's not
>>>> using async exec (although the "then()" method does not exist).
>>>>
>>>>
>>> was supposed to represent the different flavours (thenRun, thenCompose,
>>> ...) ;).
>>>
>>> That said I agree on the state switching the pool is better but with
>>> these 2 notes:
>>>
>>> - could be better to hide these poorly designed methods then -> don't
>>> use CompletionXXX but a CDI API with a bridge to CompletionX to let the
>>> user go back on SE tools
>>> - we still don't have a *standard* config for the pool(s) underlying CDI
>>> features so it sounds as poor as SE solution IMO (at least a core/max/ttl
>>> config in beans.xml)
>>>
>>>
>>>>
>>>>>  >
>>>>>  >>
>>>>>  >> 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>
>>>>>  >>
>>>>>  >>
>>>>>  >>
>>>>>  >> _______________________________________________
>>>>>  >> cdi-dev mailing list
>>>>>  >> cdi-dev at lists.jboss.org <mailto: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.
>>>>>  >>
>>>>>  >
>>>>>  > --
>>>>>  > Martin Kouba
>>>>>  > Software Engineer
>>>>>  > Red Hat, Czech Republic
>>>>>
>>>>>
>>>> --
>>>> Martin Kouba
>>>> Software Engineer
>>>> Red Hat, Czech Republic
>>>>
>>>
>>> _______________________________________________
>>> 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 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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160307/30de3113/attachment-0001.html