Skip to main content

[jsr236-spec users] [jsr236-experts] Re: On ManagedTaskListener related APIs in MES and MSES

  • From: Anthony Lai < >
  • To:
  • Subject: [jsr236-spec users] [jsr236-experts] Re: On ManagedTaskListener related APIs in MES and MSES
  • Date: Thu, 13 Dec 2012 16:13:16 -0800
  • List-id: <jsr236-experts.concurrency-ee-spec.java.net>

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:
" type="cite">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 ">< >
To:         ">
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 ">< >
To:        
">
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 ">< >
To:        
">
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 ">< >
To:        
">
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:        
">
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 ">< >
To:        
">
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











[jsr236-spec users] [jsr236-experts] Re: On ManagedTaskListener related APIs in MES and MSES

(continued)

[jsr236-spec users] [jsr236-experts] Re: On ManagedTaskListener related APIs in MES and MSES

Nathan Rauh 12/06/2012

Message not available

[jsr236-spec users] [jsr236-experts] Re: On ManagedTaskListener related APIs in MES and MSES

Nathan Rauh 12/07/2012

[jsr236-spec users] [jsr236-experts] Re: On ManagedTaskListener related APIs in MES and MSES

Anthony Lai 12/07/2012

[jsr236-spec users] [jsr236-experts] Re: On ManagedTaskListener related APIs in MES and MSES

Nathan Rauh 12/08/2012

[jsr236-spec users] [jsr236-experts] Re: On ManagedTaskListener related APIs in MES and MSES

Anthony Lai 12/11/2012

[jsr236-spec users] [jsr236-experts] Re: On ManagedTaskListener related APIs in MES and MSES

Nathan Rauh 12/11/2012

[jsr236-spec users] [jsr236-experts] Re: On ManagedTaskListener related APIs in MES and MSES

Anthony Lai 12/12/2012

[jsr236-spec users] [jsr236-experts] Re: Re: On ManagedTaskListener related APIs in MES and MSES

Nathan Rauh 12/13/2012

[jsr236-spec users] [jsr236-experts] Re: On ManagedTaskListener related APIs in MES and MSES

Anthony Lai 12/13/2012

[jsr236-spec users] [jsr236-experts] Re: On ManagedTaskListener related APIs in MES and MSES

Nathan Rauh 12/13/2012

[jsr236-spec users] [jsr236-experts] Re: On ManagedTaskListener related APIs in MES and MSES

Anthony Lai 12/14/2012

[jsr236-spec users] [jsr236-experts] Re: On ManagedTaskListener related APIs in MES and MSES

Nathan Rauh 12/14/2012

[jsr236-spec users] [jsr236-experts] Re: On ManagedTaskListener related APIs in MES and MSES

Anthony Lai 12/14/2012

[jsr236-spec users] [jsr236-experts] Re: On ManagedTaskListener related APIs in MES and MSES

Nathan Rauh 12/14/2012
 
 
Close
loading
Please Confirm
Close