You've lost me.
Are you talking about configuring what executors the container implementation itself
should use or what custom executors an application developer can use?
The best I can understand what your saying applies to the container implementation itself.
Then again, implementations like WebLogic, WebSphere and GlassFish allow you to configure
even the core executor pool of the runtime. It most certainly allows creating custom
executors pools.
The only difference would be making what is vendor specific today completely standardized.
Since when is that a bad thing?
On Mar 7, 2016, at 8:19 AM, Romain Manni-Bucau
<rmannibucau(a)gmail.com> wrote:
2016-03-07 14:15 GMT+01:00 Reza Rahman <reza_rahman(a)lycos.com>:
> I am really confused now. Why shouldn't Java EE concurrency not be able to define
a standard way to configure custom executors? You can do that today, just in vendor
specific ways...
>
Cause there are several libs where you don't control the pool and the best you can do
is to wrap the task (Runnable) on your side. Also you can hit it in background threads you
can't enforce to use concurrency spec and finally you can hit it in fully synchronous
way if you execute after the CDI chain - which is allowed by CDI and TCK-ed so you can
need a way to stack the context to reuse some part after. Last "?": JTA
integration: you can also hit it to save data after @TransactionScoped for audit
purposes.
>> On Mar 7, 2016, at 5:10 AM, Romain Manni-Bucau <rmannibucau(a)gmail.com>
wrote:
>>
>>
>> 2016-03-07 10:57 GMT+01:00 Martin Kouba <mkouba(a)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>>:
>>>>
>>>>
>>>> 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>>> 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?
>>
>>>>
>>>>
>>>> >
>>>> >>
>>>> >> 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>>
>>>> >>
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
>>
>> _______________________________________________
>> cdi-dev mailing list
>> cdi-dev(a)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(a)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.