[CONCURRENCY_EE_SPEC-22] Simplify MES, MSES APIs regarding ManagedTaskListener Created: 10/Dec/12  Updated: 27/Dec/12  Resolved: 27/Dec/12

Status: Closed
Project: concurrency-ee-spec
Component/s: None
Affects Version/s: None
Fix Version/s: Public Review

Type: Task Priority: Major
Reporter: anthony.lai Assignee: anthony.lai
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
is related to CONCURRENCY_EE_SPEC-14 Add interface to provide hint for dis... Closed

 Description   

Reduce the number of new APIs in ManagedExecutorService and ManagedScheduledExeuctorService. Currently we have 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,



 Comments   
Comment by anthony.lai [ 11/Dec/12 ]

From Nathan:
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.

Comment by anthony.lai [ 11/Dec/12 ]

From Anthony:
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?

Comment by anthony.lai [ 11/Dec/12 ]

From Nathan:
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.

Comment by anthony.lai [ 12/Dec/12 ]

Proposed 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)
Comment by anthony.lai [ 14/Dec/12 ]

2 more methods for ManagedExecutors

  • static Runnable managedTask(Runnable task, Properties executionProperties, ManagedTaskListener taskListener)
  • static <T> Callable<T> managedTask(Callable<T> callable, Properties executionProperties, ManagedTaskListener taskListener)
Comment by anthony.lai [ 27/Dec/12 ]

Proposed changes made.

Minor changes to execution property names:
DISTRIBUTABLE_HINT - true or false
CONTEXTUAL_CALLBACK_HINT - true or false

ContextService.createContextObject renamed to createContextualProxy





[CONCURRENCY_EE_SPEC-21] Add default objects similar to EE5.20 and EE5.21 Created: 10/Dec/12  Updated: 27/Dec/12  Resolved: 27/Dec/12

Status: Closed
Project: concurrency-ee-spec
Component/s: None
Affects Version/s: None
Fix Version/s: Public Review

Type: Task Priority: Major
Reporter: anthony.lai Assignee: anthony.lai
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

I really like the idea of default instances that would be consistent with other resource types in EE 7 as Anthony pointed out. For the majority of apps, this would provide a simple, zero-configuration way to use ManagedExecutorService/ScheduledExecutorService/ContextService/ThreadFactory that is easily and straightforwardly overridable by the deployer. Writing this up would just involve copying from EE 7 section 5.20 or 5.21 and replacing with the JSR 236 resource types, but on top of that I would recommend that we standardize a minimum set of contexts that must be propagated by the default instances, provided the container supports those contexts. Naming/classloader/security as mentioned previously would make sense.



 Comments   
Comment by anthony.lai [ 11/Dec/12 ]

need to work with Java EE 7 spec lead to incorporate these default objects into the Java EE 7 Platform spec.

Comment by anthony.lai [ 27/Dec/12 ]

Added requirement to Java EE Product Provider to provide default ManagedExecutorService, ManagedScheduledExecutorService, ContextService, and ManagedThreadFactory.





[CONCURRENCY_EE_SPEC-16] Distributable executors possibly overlapping asynchronous EJB Created: 02/Nov/12  Updated: 27/Dec/12  Resolved: 27/Dec/12

Status: Closed
Project: concurrency-ee-spec
Component/s: None
Affects Version/s: None
Fix Version/s: Public Review

Type: Improvement Priority: Major
Reporter: anthony.lai Assignee: Unassigned
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

David M. Lloyd wrote:
> I am concerned at the level of overlap between asynchronous EJB
> execution and distributable executors. It seems that distributable
> execution, especially with affinity, is largely the same as calling a
> singleton EJB configured with bean-managed concurrency.
>
> Are we sure that this has a place in the spec?

>I can configure a singleton EJB which allows fully concurrent access. I can then use regular invocations to do basically the same thing as distributable executors - execute tasks >on remote nodes, possibly with results.



 Comments   
Comment by anthony.lai [ 27/Dec/12 ]

Closing issue for now as no further input from David.

The spec does not require Java EE Produce Providers to supply distributable executor service. It is an optional feature.





[CONCURRENCY_EE_SPEC-14] Add interface to provide hint for distributed execution Created: 15/Aug/12  Updated: 27/Dec/12  Resolved: 27/Dec/12

Status: Closed
Project: concurrency-ee-spec
Component/s: None
Affects Version/s: None
Fix Version/s: Public Review

Type: Task Priority: Major
Reporter: anthony.lai Assignee: Unassigned
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
is related to CONCURRENCY_EE_SPEC-22 Simplify MES, MSES APIs regarding Man... Closed

 Description   

Suggestion from Andrew:

For a distributed implementation it is useful for applications to provide some additional information (eg. priority or a preference as to where they might execute). Given that ManagedExecutorService extends ExecutorService which already specifies the signatures to submit(), and this is a less common use case, it might be better to have this be an interface that extends Callable and provides something like Properties getExecutionProperties(). This should definitely be optional, and could fall back to local execution.



 Comments   
Comment by anthony.lai [ 12/Dec/12 ]

Proposed changes to issue http://java.net/jira/browse/CONCURRENCY_EE_SPEC-22 could take care of this suggestion.

Comment by anthony.lai [ 27/Dec/12 ]

getExecutionProperties() added to new ManagedTask interface per CONCURRENCY_EE_SPEC-22. Added a DISTRIBUTABLE_HINT execution property to allow tasks to provide hint on whether the task can be run remotely.





Generated at Thu Mar 05 04:59:51 UTC 2015 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.