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

Mon Mar 7 17:51:02 EST 2016

Le 7 mars 2016 23:40, "Reza Rahman" <reza_rahman at lycos.com> a écrit :
>
> What hazardous hypothesis? Someone that needs a custom executor will need
to deal with one anyway - whether by needing to pass it to the observer
dispatcher or the CompletableFuture.
>
> CompletionStage is the obscure parent superinterface for the
CompletableFuture gateway API. Hence it is mostly functionally equivalent.
What's so surprising about that?
>
> What I find strangest about this, is that you started with
CompletableFuture yourself:
https://rmannibucau.wordpress.com/2016/02/25/the-promise-of-completablefuture-jax-rs2-example/.
You should already understand the issue of familiarity for that reason
alone. If CompletionStage is so great why didn't you write about it? You
are hardly alone. Look at pretty much everyone that speaks or write on the
topic. They all start with CompletebleFuture unsurprisingly.
>

Cause it is used as a promise which is irrelevant for cdi topic.

> Let's stop the polemic and be reasonable. Otherwise we risk having
another bad API in Java EE for no good reason.
>
> Sent from my iPhone
>
> On Mar 7, 2016, at 5:26 PM, Romain Manni-Bucau <rmannibucau at gmail.com>
wrote:
>
>> You can give CompletionStage a pool too. So it helps the other thread
bit not this one if we dont make any hazardeous hypothesis.
>>
>> Le 7 mars 2016 23:19, "Reza Rahman" <reza_rahman at lycos.com> a écrit :
>> >
>> > What is still true for CompletionStage? As I've indicated, it's
largely an SPI rather than an end user API like CompletableFuture. For that
reason it will never have the level of familiarity that CompletableFuture
already does.
>> >
>> > Let's kindly not argue in circles or repeat ourselves needlessly. It
accomplishes nothing productive.
>> >
>> > On Mar 7, 2016, at 5:07 PM, Romain Manni-Bucau <rmannibucau at gmail.com>
wrote:
>> >
>> >> 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.
>> >
>> >
>> > _______________________________________________
>> > 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/4bbcf012/attachment-0001.html 