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