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