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>
To: 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
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>
To: 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