I was hoping to just see context properties merged with execution
properties (on both ContextService and ManagedTask), because I think the
distinction between them is blurry (it's not always clear what is a
context property vs what is an execution property) and I don't think
customers will really care about making a distinction, and it will be more
convenient to the user if there is no need to make any distinction or
bother with separate lists of properties.
Here's a good code example of the consistency I'd like to see between
ContextService and Managed*ExecutorService:
properties = new Properties();
properties.setProperty("vendor_a.security.tokenexpiration", "15000"); //
fits the category of context property
properties.setProperty(LONGRUNING_HINT, "true"); // fits the category of
execution property
properties.setProperty("vendor_a.taskowner", "MyServlet"); // could be
either category (or even both categories)
task1 = contextService.createContextObject(task, properties,
Runnable.class);
executorService.submit(task1);
task2 = ManagedExecutors.managedTask(task, properties, listener);
managedExecutorService.submit(task2);
In either case, the user wants to submit a task with a set of properties.
They should be able to submit the same task with the same properties
regardless of whether they're submitting to a Java SE ExecutorService via
a contextual proxy vs submitting directly to a ManagedExecutorService.
On a related topic, I wonder if getIdentityName() would be better as one
of these properties.
Currently, a user has to implement a method to provide an identity name,
which, as in the other scenarios, will be inconvenient if you want to
assign an identity name to a task from a third party library.
We could get rid of the getIdentityName() method altogether, and have
properties.setProperty(IDENTITY_NAME, "MyTaskName");
This would also allow for associating an identity name with a contextual
proxy, which would be useful.
Nathan Rauh
____________________________________________
Software Engineer, WebSphere Application Server
IBM Rochester Bldg 002-2 C111
3605 Highway 52N
Rochester, MN 55901-7802
From: Anthony Lai <anthony.lai_at_oracle.com>
To: jsr236-experts_at_concurrency-ee-spec.java.net
Date: 12/13/2012 04:53 PM
Subject: [jsr236-experts] Re: On ManagedTaskListener related APIs
in MES and MSES
Thanks for the clarification!
I suppose we can allow for this by adding a getContextProperties() method
in the new ManagedTask interface. But we won't be able to do much to
standardize what its values might be.
Regards
Anthony
On 12/13/12 7:28 AM, Nathan Rauh wrote:
I don't really see context properties being used by applications to add
more context (Either to ContextService or
ManagedExecutorService/ManagedScheduledExecutorService). I tend to see
the administrator who configures a ContextService controlling which
context can/cannot be propagated by that ContextService, allowing nothing
to be propagated beyond that). I see context properties specified by the
application as being used to refine (or possibly even limit) on a per-task
basis the context that is available to propagate. Similarly context
properties can be used by an app when using ContextService to create a
contextual proxy to refine/limit the context that it runs with. I think
these will tend to be vendor-specific, such as the example that's used in
the ContextService JavaDoc,
ctxProps.setProperty("vendor_a.security.tokenexpiration", "15000");
which would be equally useful, for example, for a task submitted to a
ManagedScheduledExecutorService.
Nathan Rauh
____________________________________________
Software Engineer, WebSphere Application Server
IBM Rochester Bldg 002-2 C111
3605 Highway 52N
Rochester, MN 55901-7802
From: Anthony Lai <anthony.lai_at_oracle.com>
To: jsr236-experts_at_concurrency-ee-spec.java.net
Date: 12/12/2012 01:04 PM
Subject: [jsr236-spec users] [jsr236-experts] Re: On
ManagedTaskListener related APIs in MES and MSES
Thanks. I think Andrew has also mentioned something similar before. Do you
have some use cases how this feature could be used?
What kind of context information would be useful to specify in per-task
basis? If it would be the standard ones that we were discussing before,
ie, naming/classloader/security, would this mechanism allow tasks to
request additional context type to be propagated on a per-task basis?
Suppose a MES is configured to not propagate security context, but a task
is submitted to that MES requesting security context to be propagated,
should the app server honor such request? Or would the context property be
used for something else? If so, what would be some examples? As you
pointed out earlier, we should try to standardize as much as these
properties as possible.
I suspect that I am somewhat confused about this feature. Any help to
clarify is appreciated.
Regards
Anthony
On 12/11/12 3:37 PM, Nathan Rauh wrote:
Yes, I think it will be desirable for applications to be able to specify
context properties at the per-task level, just as they are able to specify
context properties at the per-contextual proxy instance level.
Nathan Rauh
____________________________________________
Software Engineer, WebSphere Application Server
IBM Rochester Bldg 002-2 C111
3605 Highway 52N
Rochester, MN 55901-7802
From: Anthony Lai <anthony.lai_at_oracle.com>
To: jsr236-experts_at_concurrency-ee-spec.java.net
Date: 12/11/2012 05:14 PM
Subject: [jsr236-experts] Re: On ManagedTaskListener related APIs
in MES and MSES
This is great! Thanks.
One suggestion you made is to include context properties in
getExecutionProperties(). Currently the context to be propagated when
tasks are submitted to MES or MSES are defined in the MES/MSES
configuration. Are you suggesting that we should also allow tasks to
specify context information?
To sum up, we are planning to make the following changes:
ManagedExecutorService:
- Removal of all 7 APIs:
- <T> List <Future<T>> invokeAll(Collection<? extends Callable<T>>
tasks, long timeout, TimeUnit unit, ManagedTaskListener taskListener)
- <T> List<Future<T>> invokeAll(Collection<? extends Callable<T>>
tasks, ManagedTaskListener taskListener)
- <T> T invokeAny(Collection<? extends Callable<T>> tasks, long
timeout, TimeUnit unit, ManagedTaskListener taskListener)
- <T> T invokeAny(Collection<? extends Callable<T>> tasks,
ManagedTaskListener taskListener)
- <T> Future<T> submit(Callable<T> task, ManagedTaskListener
taskListener)
- Future<?> submit(Runnable task, ManagedTaskListener taskListener)
- <T> Future<T> submit(Runnable task, T result, ManagedTaskListener
taskListener)
- it is now possible to receive ManagedTaskListener events using the void
execute(Runnable command) method from the base class Executor.
ManagedScheduledExecutorService
- remove the following 4 APIs:
- <V> ScheduledFuture<V> schedule(Callable<V> callable, long delay,
TimeUnit unit, ManagedTaskListener taskListener)
- ScheduledFuture<?> schedule(Runnable command, long delay, TimeUnit
unit, ManagedTaskListener taskListener)
- ScheduledFuture<?> scheduleAtFixedRate(Runnable command, long
initialDelay, long period, TimeUnit unit, ManagedTaskListener
taskListener)
- ScheduledFuture<?> scheduleWithFixedDelay(Runnable command, long
initialDelay, long delay, TimeUnit unit, ManagedTaskListener taskListener)
- APIs that use Trigger would have the taskListener argument removed, and
become:
- <V> ScheduledFuture<V> schedule(Callable<V> callable, Trigger
trigger)
- ScheduledFuture<?> schedule(Runnable command, Trigger trigger)
ManagedTask
- optionally implemented by tasks (Runnable or Callable) submitted to MES
and MSES
- replaces Identifiable
- contains these methods:
- String getIdentityDescription(Locale locale)
- String getIdentityName()
- ManagedTaskListener getManagedTaskListener()
- Properties getExecutionProperties()
- Predefined constants for execution property names and values include
- DISTRIBUTABLE: LOCAL (default), DISTRIBUTABLE,
DISRTIBUTABLE_WITH_AFFINITY
- LONGRUNNING_HINT: TRUE, FALSE (default)
One other possible property we may add here is for contextual callback,
eg.
- CONTEXTUAL_CALLBACK: TRUE, FALSE (default)
ManagedExecutors
- new utility methods to add ManagedTaskListener to Runnable and Callable
- static Runnable managedTask(Runnable task, ManagedTaskListener
taskListener)
- static <T> Callable<T> managedTask(Callable<T> callable,
ManagedTaskListener taskListener)
Comments are welcome!
Regards
Anthony
On 12/8/12 11:31 AM, Nathan Rauh wrote:
Yes, that's a valid use case. It would still be possible to register a
ManagedTaskListener for a task that's provided by a library or third party
-- by wrapping it with a ManagedTask.
For example,
Runnable r = new MyManagedTaskProxy(runnableFrom3rdPartyLibrary,
managedTaskListener); // implements Runnable and ManagedTask
managedExecutorService.submit(r);
I'm not sure how common this will be. It does make this scenario more
difficult.
If we want to go this direction, a further step that could be taken to
help here is to provide static convenience methods,
ManagedExecutors.managedTask(runnable/callable, ManagedTaskListener)
along the lines of what the Java SE concurrent package does for
Executors.callable(Runnable) or Executors.callable(PrivilegedAction)
so the that application doesn't need to implement its own proxy,
Runnable r = ManagedExecutors.managedTask(runnable, listener);
managedExecutorService.submit(r);
As you pointed out, the mix-in interface approach could also solve JIRA
issue 14.
ManagedTask could have a method,
.getExecutionProperties()
instead of
.getContextProperties()
since context properties and distributed execution properties are both
particular types of execution properties (We should also update
ContextService here, so that it refers to execution properties, and is not
limited to context properties).
I would recommend that we try to standardize any known execution
properties as much as possible so that we don't end up encouraging
non-portable apps.
In addition to whatever particular information for distributed execution
was requested under issue 14, one piece of information that I think will
be useful for task execution is a IS_LONG_RUNNING=true/false hint, since
an implementation might want to make use of that sort of information when
deciding how to allocate work to a thread pool.
Nathan Rauh
____________________________________________
Software Engineer, WebSphere Application Server
IBM Rochester Bldg 002-2 C111
3605 Highway 52N
Rochester, MN 55901-7802
From: Anthony Lai <anthony.lai_at_oracle.com>
To: jsr236-experts_at_concurrency-ee-spec.java.net
Date: 12/07/2012 03:41 PM
Subject: [jsr236-experts] Re: On ManagedTaskListener related APIs
in MES and MSES
I like this idea. We could also use this mix-in interface to provide hints
for distributed execution, as tracked by jira issue 14.
But this seems to tightly couple the task implementation with the
ManagedTaskListener implementation. Suppose an application developer
schedules a task which is provided by some library but needs to monitor
the task using a ManagedTaskListener that he/she writes. Is this a valid
use case and do we need to worry about such scenarios?
Regards
Anthony
On 12/7/12 11:52 AM, Nathan Rauh wrote:
The proposal about ManagedTaskListener is also interesting because I
remember in one of the posts (which we never really addressed) where
someone asked about specifying context properties on tasks submitted to a
managed executor service. That's a very similar scenario in that it would
also require additional method signatures.
I gave some more thought to whether there are any other alternatives, and
I think a better alternative than what I mentioned previously could be a
mix-in interface that provides a getManagedTaskListener.
We already have Identifiable being used here as a mix-in interface. We
could convert Identifiable into something more general, say ManagedTask,
and then add a getManagedTaskListener (and possibly also a
getContextProperties) to it.
So the idea here would be to replace
javax.enterprise.concurrent.Identifiable
.getIdentityName()
.getIdentityDescription(Locale)
with
javax.enterprise.concurrent.ManagedTask
.getIdentityName()
.getIdentityDescription(Locale)
.getManagedTaskListener()
.getContextProperties() ?
and then we could meet the request of removing all of the method
signatures on ManagedExecutorServce/ManagedScheduledExecutorService which
copy from ExecutorService/ScheduledExecutorService without introducing the
unpredictable behavior that would be introduced by
ManagedExecutorService.add/removeManagedTaskListener.
Nathan Rauh
____________________________________________
Software Engineer, WebSphere Application Server
IBM Rochester Bldg 002-2 C111
3605 Highway 52N
Rochester, MN 55901-7802
From: Nathan Rauh/Rochester/IBM
To: jsr236-experts_at_concurrency-ee-spec.java.net
Date: 12/06/2012 02:53 PM
Subject: Re: [jsr236-experts] On ManagedTaskListener related APIs
in MES and MSES
Anthony,
I agree with your concerns about what happens when multiple applications
register listeners to the same managed executor service. I think it would
cause too much unexpected behavior, and we should not switch to
add/removeManagedTaskListener.
The only other alternative I can think of for avoiding the
ManagedTaskListener copies of the method signatures is to allow for
submitted tasks to optionally implement ManagedTaskListener, but that
would be kind of awkward and would seem to make taskStarting/taskDone
notifications redundant with the beginning and end of the run/call method.
Nathan Rauh
____________________________________________
Software Engineer, WebSphere Application Server
IBM Rochester Bldg 002-2 C111
3605 Highway 52N
Rochester, MN 55901-7802
From: Anthony Lai <anthony.lai_at_oracle.com>
To: jsr236-experts_at_concurrency-ee-spec.java.net
Date: 12/05/2012 04:42 PM
Subject: [jsr236-experts] On ManagedTaskListener related APIs in
MES and MSES
Dear experts,
There is recently a suggestion on the MES and MSES APIs that I would
like to get opinions from the expert group.
The idea was instead of having 7 new APIs in the ManagedExecutorService
and 4 in ManagedScheduledExecutorService whose only difference from the
ones in the super class in java.util.concurrent package was the addition
of an extra parameter for ManagedTaskListener, could we replace them
with an addTaskListener and removeTaskListener to the
ManagedExecutorService interface?
Pros:
- Much fewer new APIs in MES and MSES
- Easier to register same ManagedTaskListener to monitor events for all
task submissions. For example, an application can register a single
ManagedTaskListener to an MES receive all events related to task
submissions.
Cons:
- Becomes awkward when need to specify a different ManagedTaskListener
for each task submission
- Management of list of task listeners, especially if the MES is shared
across multiple applications and that applications that registers the
listener may be undeployed.
I tend to prefer the current APIs, but I would like to bring this up and
see if anyone have different opinions or suggestions.
Regards
Anthony