[cdi-dev] async: back to completion future?
Romain Manni-Bucau
rmannibucau at gmail.com
Mon Mar 7 10:12:53 EST 2016
2016-03-07 16:03 GMT+01:00 Reza Rahman <reza_rahman at lycos.com>:
> Comments in-line:
>
> On Mar 7, 2016, at 8:52 AM, Romain Manni-Bucau <rmannibucau at gmail.com>
> wrote:
>
>
> 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
>
>
> This is what concerns me the most. I'd like to see this standardized. If
> there isn't anything that I am missing here, there is not much for me to
> discuss.
>
> 2. add an API to control the context and its propagation cleanly
>
>
> You mean a CDI API to further control life cycle? I'd like to see a
> concrete proposal before I comment on this. This sounds to me like there
> isn't an easy solution to it.
>
>
To share the idea:
ContextView view= beanManager.createContextView(RequestScoped.class);
new Runnable() {
public void run() {
ContextView old = beanManager.restore(RequestScoped.class, view);
try {
// work
} finally {
beanManager.restore(RequestScoped.class, old);
}
}
};
> 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)
>
>
> Already discussed my thoughts on this. I don't think there is a need to
> repeat that here.
>
>
> 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".
>
>
> This is where you lost me again. Are you arguing for standardizing what is
> proprietary today or not?
>
>
Yep I'm for.
>
>
>> 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.
>>
>
>
> _______________________________________________
> 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/6531e9b1/attachment-0001.html
More information about the cdi-dev
mailing list