[cdi-dev] async: back to completion future?
Romain Manni-Bucau
rmannibucau at gmail.com
Mon Mar 7 08:52:12 EST 2016
2016-03-07 14:47 GMT+01:00 Reza Rahman <reza_rahman at lycos.com>:
> I am still confused what the issue is. Let's do this another way.
>
> What do you propose as a solution for EE overall? Are you simply saying
> the current proprietary ways of configuring executors are not good?
>
>
Solutions:
1. standardize the basic pool configs
2. add an API to control the context and its propagation cleanly
3. (i don't know about the tck part so this is a maybe) fix/enhance the
integration between concurrency and cdi specs if needed (TCK) + add a way
to propagate a context (maybe with concurrency utility proxy factory and a
new option in method signature)
About proprietary config: yes this is generally bad to rely on it too much
for internals of an app. A thread pool is an internal of an app -
understand it as opposed to "a MySQL/Oracle datasource".
> On Mar 7, 2016, at 8:39 AM, Romain Manni-Bucau <rmannibucau at gmail.com>
> wrote:
>
>
> 2016-03-07 14:34 GMT+01:00 Reza Rahman <reza_rahman at lycos.com>:
>
>> 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?
>>
>>
> Both cases
>
>
>> 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?
>>
>>
> I'm for this standardization - even if just a subset of vendors config but
> the minimum to ensure an app can scale on all servers. The bad thing is
> when the feature is central or important for an app. Then you hide a
> proprietary feature behind a standard API, this is very nasty and can lead
> to broken usages pretty easily.
>
> However my last point is: even if you fix it for the container you still
> have the app use cases where the pool are sometimes hidden in apps themself
> and EE concurrency doesn't help there (and just taking few remote libs it
> is not rare at all).
>
>
>> On Mar 7, 2016, at 8:19 AM, Romain Manni-Bucau <rmannibucau at gmail.com>
>> wrote:
>>
>> 2016-03-07 14:15 GMT+01:00 Reza Rahman <reza_rahman at 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 at gmail.com>
>>> wrote:
>>>
>>>
>>> 2016-03-07 10:57 GMT+01:00 Martin Kouba <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>>:
>>>>>
>>>>>
>>>>> 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>>> 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 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
>>>>
>>>
>>> _______________________________________________
>>> 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/d66a4e8d/attachment-0001.html
More information about the cdi-dev
mailing list