Hi Fred,
Do you have suggestion on how should an application developers write an
application that use MTF that could be deployed on servers that may not
support MTF?
Regards
Anthony
On 8/9/12 6:49 AM, Frederick W Rowe wrote:
> Hi Anthony,
>
> Sorry to be long in responding. I would say that an application
> doesn't need to handle the absence of an MTF impl because if the app
> depends on it, it doesn't make any sense to run it on an app server
> that doesn't support it. I suppose if you wanted the app to run on
> both types of server (one that impls MTF and one that doesn't), you
> could code it to handle the absence of an MTF with a TF, but that
> would be violating the best practice for apps to not create threads
> anyway. So, I would argue that making it optional doesn't make apps
> have to handle the lack of an MTF since they can't be "well behaved"
> without it.
> As to MSES, I don't think it should be required either. I can think
> of many usecases where I need to create a managed thread and run it
> but have no need to schedule it.
> Can we agree that the minimal requirement would be MES? While one
> could argue that MTF could just as easily be the minimal requirement
> since it can be used without needing MES, I would argue that would
> likely be an advanced use case above and beyond the most common use of
> MES.
>
> Regards,
>
> Fred Rowe
>
> Senior Software Engineer
> WebSphere Architect
> IBM Software Group
> frowe_at_us.ibm.com
>
>
> *Anthony Lai <anthony.lai_at_oracle.com>*
>
> 08/01/2012 03:47 PM
> Please respond to
> jsr236-experts
>
>
>
> To
> jsr236-experts_at_concurrency-ee-spec.java.net
> cc
>
> Subject
> [jsr236-experts] Re: Feedback requested on proposed changes
>
>
>
>
>
>
>
>
>
> Hi Fred,
>
> I am open to making some of the administered objects optional. But I
> was trying to figure out what would the user code need to do if a Java
> EE container does not support some of them.
>
> Take ManagedThreadFactory as an exampel. Suppose we have the following
> in the user code:
>
> ManagedThreadFactory mtf = ... // obtain an instance either through
> JNDI lookup or resource injection
> Thread myThread = mtf.newThread();
>
> Suppose ManagedThreadFactory is optional, would mtf be null? Does the
> user code need to check for a null mtf and find alternative way to
> create a new thread?
> Would the user code need to do something like this?
>
> ManagedThreadFactory mtf = ...
> if (mtf != null) {
> myThread = mtf.newThread();
> } else {
> ThreadFactory tf =
> java.util.concurrent.Executors.defaultThreadFactory();
> myThread = tf.newThread();
> }
>
> This seems awkward and it may encourage users to bypass using JSR 236
> objects and simply use the Java SE concurrent package, and thus not
> getting a container managed thread even if it is available.
>
> Also, I would suggest that MSES should also be required.
>
> Regards
> Anthony
>
>
> On 8/1/12 3:51 AM, Frederick W Rowe wrote:
> Andrew,
> Yeah, I struggled with that same issue and since you brought it up,
> let's address it via your suggestion of making MES required and the
> rest optional.
>
> Anthony,
> Does that address the issue you raised regarding the behavior when an
> app attempts to obtain an instance of MES from a container not
> implementing it (which it would have to under the proposed wording)?
>
> Regards,
>
> Fred Rowe
>
> Senior Software Engineer
> WebSphere Architect
> IBM Software Group_
> __frowe_at_us.ibm.com_ <mailto:frowe_at_us.ibm.com>
>
> *Andrew Evers **_<andrew.evers_at_gmail.com>_*
> <mailto:andrew.evers_at_gmail.com>
>
> 07/31/2012 10:14 PM
> Please respond to
> jsr236-experts
>
>
> To
> _"jsr236-experts_at_concurrency-ee-spec.java.net"_
> <mailto:jsr236-experts_at_concurrency-ee-spec.java.net>_<jsr236-experts_at_concurrency-ee-spec.java.net>_
> <mailto:jsr236-experts_at_concurrency-ee-spec.java.net>
> cc
>
> Subject
> [jsr236-experts] Re: Feedback requested on proposed changes
>
>
>
>
>
>
>
>
>
>
>
> Hi guys,
>
> I think at least something needs to be required, otherwise
> implementing nothing would be JSR236 compliant, which is a bit odd.
>
> Of the four ManagedExecutorService is the obvious candidate for being
> the baseline, and (as Fred mentions) ManagedScheduledExecutorService
> is a fairly close second. This gives applications (the reason app
> servers exist) access to additional managed threads, and to basic
> background processing in a standard manner. This would obviously only
> need to be a local implementation.
>
> 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.
>
> On the subject of context, access to security and naming context in
> run()/call() are definitely the most important. The other methods are
> unlikely to be more than a few lines, or need contextual information.
>
> Regards,
>
> Andrew.
>
> On Thursday, 26 July 2012, Frederick W Rowe wrote:
> All,
>
> In addition to the previous changes, I'd like to request the following
> change to Section 3 below. Currently, all four APIs are required to
> be implemented. There are use cases where only one of them might be
> needed, I'd propose making the implementation of any of them optional,
> except if implemented, ManagedScheduledExecutorService obviously
> requires an impl of ManagedExecutorService.*
>
> 3 Administered Objects*
> This section introduces four programming interfaces for Java EE
> Product Providers to implement (see
> J2EE.2.11 for a detailed definition of each of the roles described
> here). Instances of these interfaces
> must be made available to application components through containers as
> administered objects:
> • Section 3.1, "ManagedExecutorService" –The interface for submitting
> asynchronous tasks from
> a container.
> • Section 3.2, "ManagedScheduledExecutorService" – The interface for
> scheduling tasks to run
> after a given delay or execute periodically.
> • Section 3.3, "ContextService" – The interface for creating
> contextual objects.
> • Section 3.4, "ManagedThreadFactory" – The interface for creating
> managed threads.
>
> Regards,
>
> Fred Rowe
>
> Senior Software Engineer
> WebSphere Architect
> IBM Software Group_
> __frowe_at_us.ibm.com_ <javascript:_e({}, 'cvml', 'frowe_at_us.ibm.com');>
>
> *Anthony Lai <**_anthony.lai_at_oracle.com_* <javascript:_e({}, 'cvml',
> 'anthony.lai_at_oracle.com');>*>*
>
> 06/22/2012 07:19 PM
>
>
> Please respond to
> jsr236-experts
>
>
> To
> _jsr236-experts_at_concurrency-ee-spec.java.net_ <javascript:_e({},
> 'cvml', 'jsr236-experts_at_concurrency-ee-spec.java.net');>
> cc
>
> Subject
> [jsr236-experts] Feedback requested on proposed changes
>
>
>
>
>
>
>
>
>
>
>
>
>
> Dear experts,
>
> Fred has suggested the following changes. They are in the annotations
> that he added to the PDF file that he sent out, and I forwarded to the
> list on his behalf, a few days back. I am sending this out in case
> anyone has missed it. (Fred - I hope I didn't miss anything.)
>
> 1. The following contextual invocation points listed section 2.3.1
> should be made optional
> ManagedTaskListener
> - taskAborted()
> - taskSubmitted()
> - taskStarting()
> Trigger
> - getNextRunTime()
> - skipRun()
> We should make all of these optional as contextual invocation points. It
> seems inefficient to be propagating context to all of these by default,
> which I suspect in a lot of cases won't be used. Let the
> ManagedExecutorService/ManagedScheduledExecutorService provide its own
> config options to control this as an optional behavior.
>
> 2. Remove component-managed from the spec
> We should remove component-managed from the spec, because this function
> is duplicate of what a user would get by supplying a
> ManagedThreadFactory to a Java SE executor service.
>
> Regarding the sentence "If the threads are pooled, the overhead of
> reusing a thread disappears since the context does not have to change
> the thread’s context." - This statement isn't entirely accurate. Think
> of security context, where different users are running the same
> component. It would be an error to keep reusing the context of user1 on
> pooled threads for user2 and user3 who are also using the component. The
> the security context will be all wrong. This is another reason why we
> want to get rid of Component-Managed Executor. If we instead let it be
> the component's responsibility to get this behavior by supplying a
> ManagedThreadFactory to a Java SE executor service, then it will be
> clear to the component exactly what they're doing.
>
>
> 3. Distributable ManagedExeutorService should be optional
> ([Anthony] I think it is implied in section 3.1.3.1.1 where only "Local"
> is required but we should make it more obvious)
>
> 4. Remove the following requirements from section 3.5.1
> " - Tasks submitted to the master executor are owned by the executor
> instance. If the master executor becomes unavailable, the submitted
> tasks are cancelled.
> - All tasks are not considered to be idempotent. If a slave executor
> becomes unavailable, all Futures for the tasks submitted to that
> executor that have not yet started will be cancelled.
> - If a slave executor becomes unavailable, and the task has started, the
> result of the task’s Future will throw a
> javax.enterprise.concurrent.ExecutorNotAvailableException exception. "
>
> The Distributed ManagedExecutorService/ManagedScheduledExecutorService
> should be free to submit to a different "slave" or to run the task itself.
>
> 5. Section 4 Managed Object should be optional
>
> Comments are welcome.
>
> Regards
> Anthony
>