[cdi-dev] async: back to completion future?
Romain Manni-Bucau
rmannibucau at gmail.com
Mon Mar 7 05:20:55 EST 2016
2016-03-07 11:17 GMT+01:00 Martin Kouba <mkouba at redhat.com>:
>
>
> Dne 7.3.2016 v 11:10 Romain Manni-Bucau napsal(a):
>
>>
>> 2016-03-07 10:57 GMT+01:00 Martin Kouba <mkouba at redhat.com
>> <mailto:mkouba at redhat.com>>:
>>
>> Dne 7.3.2016 v 09:45 Romain Manni-Bucau napsal(a):
>>
>> 2016-03-07 9:07 GMT+01:00 Martin Kouba <mkouba at redhat.com
>> <mailto:mkouba at redhat.com>
>> <mailto:mkouba at redhat.com <mailto: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>
>> <mailto:mkouba at redhat.com <mailto:mkouba at redhat.com>>
>> <mailto:mkouba at redhat.com <mailto:mkouba at redhat.com>
>> <mailto: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
>>
>>
>> Yep, this is one of the possible solutions. On the other hand, I
>> don't think it's poorly designed. CompletionStage defines the
>> "default asynchronous execution facility" and CDI spec states that
>> the CompletionStage returned by fireAsync methods is
>> container-specific. The impl may choose to clarify this "default
>> asynchronous execution facility", i.e. there's place for innovation...
>>
>> - 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)
>>
>>
>> I don't think this should be standardized...
>>
>>
>> Why? Typically if you take @Asynchronous (EJB spec) you have already
>> this issue and this is often avoided when portability matters for that
>> particular reason you don't know how you will behave. Or do you think
>> concurrency-utilities solves it?
>>
>
> No, it doesn't. I think it should remain impl-specific. You know how it
> will behave - it will be async. And if needed you could tune up the config,
> depending on the container. If you specify core/max/ttl the container will
> not be able to optimize.
>
>
"it will be async" <- then container is free to have a single thread (would
make a js impl possible :)) which would totally break you app which is
supposed to be scalable. Also if the config is container dependent you can
just not be able to configure it - I know the container would be bad but
you don't always choose it. In any case not having a config means the
feature is not reliable and depending on the container specific features
means you are aside the EE goals of reliability in the time IMHO.
Also the container opitmizations can have side effects so if not behaving
as expected it needs to be spec-ed.
Threading model is something central when it starts to be used for a bit
mroe than fire and forget once a day, ignoring it is killing before the
birth the API you can add on top of it 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>
>> >>
>> >>
>> >>
>> >> _______________________________________________
>> >> cdi-dev mailing list
>> >> cdi-dev at lists.jboss.org
>> <mailto:cdi-dev at lists.jboss.org> <mailto:cdi-dev at lists.jboss.org
>> <mailto:cdi-dev at lists.jboss.org>>
>> <mailto:cdi-dev at lists.jboss.org
>> <mailto:cdi-dev at lists.jboss.org> <mailto: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
>>
>>
>>
>> --
>> Martin Kouba
>> Software Engineer
>> Red Hat, Czech Republic
>>
>>
>>
> --
> Martin Kouba
> Software Engineer
> Red Hat, Czech Republic
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160307/130e7584/attachment-0001.html
More information about the cdi-dev
mailing list