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

Mon Mar 7 17:07:20 EST 2016

Side note: this is still true for CompletionStage.
Le 7 mars 2016 22:48, "Reza Rahman" <reza_rahman at lycos.com> a écrit :

> Not sure how alias works, so resending directly. Responses inline.
>
> The bottom line is that we should think about the usability of the most
> common end user. If anyone needs custom executor service control in the
> worst case it's still just a matter of one extra parameter as opposed to
> introducing an obscure alternative to CompletableFuture.
>
> On Mar 7, 2016, at 4:38 PM, Reza Rahman <reza_rahman at lycos.com> wrote:
>
> Responses in-line.
>
> Sent from my iPhone
>
> On Mar 7, 2016, at 4:24 PM, Romain Manni-Bucau <rmannibucau at gmail.com>
> wrote:
>
>
> 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.
>
>
> For framework developers usability is hardly a concern. If they need to
> preserve their own context they can simply pass in their own managed
> executor to both the observer thread and the CompletableFuture.
>
> In the end, the primary focus should be the masses that we hope will adopt
> CDI into their applications. Making things harder for them to achieve some
> limited SPI goal is pretty dangerous.
>
>
>> 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.
>
>
> There is no such thing as context propagation outside of EE managed
> executors. In SE land, the only thing you have is manually writing your own
> executor to do the same things. These folks will have to pass around their
> own executors anyway, even to the observer thread.
>
> 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.
>>
>
>
> _______________________________________________
> 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/c0c4e33f/attachment-0001.html 