Re: [cdi-dev] async: back to completion future?

Comments in-line: On Mar 7, 2016, at 8:52 AM, Romain Manni-Bucau <rmannibucau(a)gmail.com&gt; wrote: 2016-03-07 14:47 GMT+01:00 Reza Rahman <reza_rahman(a)lycos.com&gt;: > 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.

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?

> On Mar 7, 2016, at 8:39 AM, Romain Manni-Bucau <rmannibucau(a)gmail.com&gt; > wrote: > > > 2016-03-07 14:34 GMT+01:00 Reza Rahman <reza_rahman(a)lycos.com&gt;: > >> 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(a)gmail.com&gt; >> wrote: >> >> 2016-03-07 14:15 GMT+01:00 Reza Rahman <reza_rahman(a)lycos.com&gt;: >> >>> 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&gt; >>> wrote: >>> >>> >>> 2016-03-07 10:57 GMT+01:00 Martin Kouba <mkouba(a)redhat.com&gt;: >>> >>>> 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(a)lists.jboss.org&gt;&gt; >>>>> >> 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. >>> >> >> >> _______________________________________________ >> 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. > _______________________________________________ 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.