Makes sense.
What about getIdentityDescription(Locale)? I suppose we need to keep it
in ManagedTask interface?
It should be noted that some properties may not be applicable in both
ContextService proxy and MES. For example, USE_PARENT_TRANSACTION does
not apply when task is being run on a thread from a thread pool.
Similarly, LONGRUNNING_HINT does not help when the ContextService proxy
method is being invoke synchronously on the same thread.
Here is an updated proposed changes we have discussed so far on the
APIs. Please review and see if they are correct:
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)
- ManagedTaskListener getManagedTaskListener()
- Properties getExecutionProperties()
- Predefined constants for execution property names and values include
- IDENTITY_NAME: any string value as name of the task
- DISTRIBUTABLE: LOCAL (default), DISTRIBUTABLE,
DISRTIBUTABLE_WITH_AFFINITY
- LONGRUNNING_HINT: TRUE, FALSE (default)
- 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)
ContextService
- replace contextProperties with executionProperties
Regards
Anthony
On 12/13/12 3:39 PM, Nathan Rauh wrote:
> 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>_
> <mailto:anthony.lai_at_oracle.com>
> To: _jsr236-experts_at_concurrency-ee-spec.java.net_
> <mailto: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>_
> <mailto:anthony.lai_at_oracle.com>
> To: _jsr236-experts_at_concurrency-ee-spec.java.net_
> <mailto: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>_
> <mailto:anthony.lai_at_oracle.com>
> To: _jsr236-experts_at_concurrency-ee-spec.java.net_
> <mailto: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_
> <mailto: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>_
> <mailto:anthony.lai_at_oracle.com>
> To: _jsr236-experts_at_concurrency-ee-spec.java.net_
> <mailto: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
>
>
>
>
>
>
>