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>_
> <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
>
>
>
>