jsr236-experts@concurrency-ee-spec.java.net

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

From: Nathan Rauh <naterauh_at_us.ibm.com>
Date: Tue, 18 Dec 2012 20:43:27 -0600

Anthony,

This looks really good. Thanks for writing it all up.

I noticed a couple of minor things (mostly just typos)


This example in ManagedExecutors has a typo
   Runnable taskWithListener = ManagedExecutors.managedTask(task,
myTaskListener);
   executor.submit(task);
It should be:
   Runnable taskWithListener = ManagedExecutors.managedTask(task,
myTaskListener);
   executor.submit(taskWithListener);


In ContextService.createContextObject, there's a typo,
"If the application component that created the proxy is started or
deployed, all methods on reflected interfaces will throw a
java.lang.IllegalStateException."
It should be:
"If the application component that created the proxy is not started or
deployed, all methods on reflected interfaces will throw a
java.lang.IllegalStateException."


In ContextService.USE_PARENT_TRANSACTION it currently reads:
"This property will be ignored when the proxy object is submitted to an
Executor..."
Contextual proxy objects typically can't be submitted to an Executor, I
think you meant:
"This property will be ignored if specified on a ManagedTask that is
submitted to an Executor..."


After seeing this in several places,
"ClassCastException - - thrown if one of the keys or values in the
specified Properties object are not of type String."
I wonder if we could better enforce this by just switching the type from
java.util.Properties to java.util.HashMap<String, String>? I think we
might have considered that before and didn't see any reason to switch it,
but this extra type checking/validation now seems like a pretty good
reason, since <String,String> will force the user to write it correctly to
begin with.


In ManagedTask.CONTEXTUAL_CALLBACK, the text currently includes:
"If this property is not specified, container context will not be
propagated to the threads that invoke the callback methods on the
ManagedTaskListener."
I think we should remove this statement, in which case if not specified,
the behavior can be implementation specific such that the container is
free to do whatever is most optimal - not having to remove context if
already there, and not having to add context if not present. By deciding
not to specify the property, the user is saying that their implementation
doesn't care one way or the other about context being available to these
listener notifications, and so the container can do whatever is most
convenient.



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/18/2012 05:53 PM
Subject: [jsr236-experts] Re: On ManagedTaskListener related APIs
in MES and MSES



Thanks, Nathan!

I have update the javadoc at http://concurrency-ee-spec.java.net/javadoc/
to capture what we have discussed so far. I have also included some minor
corrections in this update. Classes that were updated includes:

ContextService
LastExecution
ManagedExecutorService
ManagedExecutors
ManagedScheduledExecutorService
ManagedTask (replacing Identifiable)
SkippedException

Regards
Anthony



On 12/18/12 12:25 PM, Nathan Rauh wrote:
I agree - affinity only makes sense at the level of the
ManagedExecutorService.
At the per-task level, DISTRIBUTABLE=true/false as you suggested is good.

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/18/2012 12:02 PM
Subject: [jsr236-experts] Re: On ManagedTaskListener related APIs
in MES and MSES



Thanks for pointing that out. :-)

I was looking at this execution property and was wondering if
DISTRIBUTABLE_WITH_AFFINITY hint applies to a single task. It applies to
a MES or MSES so tasks submitted to the MES or MSES would be routed to
the same application server process. But what does it mean on a task?
Should a task simply provide hint saying whether it can be run in a
remote process. So instead of having:

Property name: RUN_LOCATION
Possible values: LOCAL, DISTRIBUTABLE, DISTRIBUTABLE_WITH_AFFINITY

Does it make sense to have this instead:

Property name: DISTRIBUTABLE
Possible values: "true", "false"

Regards
Anthony

On 12/18/12 7:25 AM, frowe_at_us.ibm.com wrote:
> I'm assuming that you'll correct the typo in
> "DISRTIBUTABLE_WITH_AFFINITY
> " when updating spec...