Hi Arun,
Thanks for the feedback! I did not get your mail through the users
mailing list either, but your mail does show up in the users mailing
list archive. Not sure why. I am replying to the experts mailing list so
both experts and users list subscribers could read this as well.
Please see comments below. Thanks.
On 12/4/12 5:59 AM, Arun Gupta wrote:
> Have not seen this on the alias yet so forwarding you here as well.
>
>
> -------- Original Message --------
> Subject: Feedback on Early Draft
> Date: Tue, 04 Dec 2012 10:22:30 -0200
> From: Arun Gupta <arun.p.gupta_at_oracle.com>
> Organization: Oracle
> To: users_at_concurrency-ee-spec.java.net
>
>
>
> Hi Anthony,
>
> Here is some feedback based upon Early Draft of JSR 236:
>
> 1). The first bullet in section 1.2 says " Preserve the fundamental
> capabilities and integrity of the Java EE platform. " Even though may
> be one of the goals but being the first bullet, it feels that is the
> primary goal of this JSR. IMHO the second line in second bullet is the
> primary goal instead which states " Provide a simple yet flexible API
> for application component providers to design applications using
> concurrency design principles."
Agree
>
> Isn't the first bullet an implicit goal for all specifications anyway ?
I suggest we should remove the first bullet as it seems redundant.
>
> 2). There is a submit method for Runnable and Callable. But invokeAll
> is only for Callable. Why ?
That is because the ManagedExecutorService interface extends from
java.util.concurrent.ExecutorService in Java SE, which does not have
invokeAll for Runnable.
>
> 3). Examples in 3.1.4.1.1, .2 and .3 do not show ThreadUse property in
> the table. Section 3.2.4.1.1, .2, and .3 do show that property.
I think it makes sense to have the ThreadUse property in
ManagedThreadFactory as well. But we are reviewing the configuration
sections. Currently these sections contain example configuration
attributes. It was brought up to the expert group that we should try to
define a few required attributes and remove optional ones from the spec.
>
> 4). 3.1.4 - Its not clear how/where these configuration attributes can
> be specified.
It would be depend on each application server.
>
> 5). AIU figure 3-1: each cube has a light blue box to indicate the
> task being executed and another color to indicate the application that
> initiated that task. Does the changed color of surrounding cube
> indicate the changed context ?
Yes.
>
> 6). I could not find any discussion around CDI-style
> ManagedThreadExecutor. Is that coming or not planned ?
I am assuming that by ManagedThreadExecutor you are referring to
ManagedExecutorService, ManagedScheduledExecutorService, ContextService,
and ManagedThreadFactory. Currently we are going with letting
application components to either lookup such objects via JNDI or via
@Resource annotation. Please let us know if you have better ideas.
>
> 7). Do the tasks always need to create a new UserTransaction ? Will
> setting Contextual-Callback propagate the transaction context from
> container to the tasks run by the executor ?
The context to be propagated depends on how the ContextService
referenced by an ManagedExecutorService is being configured. Typical
ones are naming, security, and classloader. Propagation of transaction
context from one thread to another is a bit trickier and it may not be
supported by all application servers. Tasks could choose to make use of
UserTransaction if they want the work to be executed within a transaction.
>
> What about security context ?
It will be propagated if configured to do so.
>
> 8). The spec talks about "execute" method where as the javadocs you
> shared has "invoke". Which one is accurate ?
Could you point me to some places where these can be found? I am not
sure exactly where you are referring to. Thanks.
>
> 9). When the job is submitted, is it executed right away or dispatched
> to a queue where it waits for execution ?
Normally a job will be dispatched to some thread pool implementation
where the job may either be executed right away or it may wait for a
thread to become available to run the job at a later time, depending on
thread pool implementation and the current work load at the time.
>
> 10). How is the thread pool configuration relates to a similar
> configuration in application server runtime ?
Are you referring to configuration in glassfish?
Regards
Anthony
>
> Thanks
> Arun
>
> Thanks,
> Arun
> --
> http://twitter.com/arungupta
> http://blogs.oracle.com/arungupta
>
>
>