11:17 a.m.
Dne 7.3.2016 v 11:10 Romain Manni-Bucau napsal(a):
2016-03-07 10:57 GMT+01:00 Martin Kouba <mkouba(a)redhat.com
<mailto:mkouba@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(a)redhat.com
<mailto:mkouba@redhat.com>
<mailto:mkouba@redhat.com <mailto:mkouba@redhat.com>>>:
Dne 7.3.2016 v 09:03 Romain Manni-Bucau napsal(a):
Le 7 mars 2016 08:35, "Martin Kouba" <mkouba(a)redhat.com
<mailto:mkouba@redhat.com>
<mailto:mkouba@redhat.com <mailto:mkouba@redhat.com>>
<mailto:mkouba@redhat.com <mailto:mkouba@redhat.com>
<mailto:mkouba@redhat.com <mailto:mkouba@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.
>
>>
>> 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(a)lists.jboss.org
<mailto:cdi-dev@lists.jboss.org> <mailto:cdi-dev@lists.jboss.org
<mailto:cdi-dev@lists.jboss.org>>
<mailto:cdi-dev@lists.jboss.org
<mailto:cdi-dev@lists.jboss.org> <mailto:cdi-dev@lists.jboss.org
<mailto:cdi-dev@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