Resending message with Fred's personal contact removed for archive purpose.
On 7/31/12 12:28 PM, Anthony Lai wrote:
> Hi Fred,
>
> Right. I guess my question is what would the application do when it is
> planning on using a ManagedExecutorService to schedule some tasks, but
> a JNDI lookup or injection of the ManagedExecutorService fail to
> return an object since the container does not support it.
>
> Regards
> Anthony
>
> On 7/31/12 12:15 PM, Frederick W Rowe wrote:
>> How would the application even get a handle to the
>> ManagedExecutorService if not implemented? For example, a jndi
>> lookup of the object would fail, as would injection of it....
>>
>> Regards,
>>
>> Fred Rowe
>>
>> Senior Software Engineer
>> WebSphere Architect
>> IBM Software Group
>> frowe_at_us.ibm.com
>>
>>
>> *Anthony Lai <anthony.lai_at_oracle.com>*
>>
>> 07/31/2012 02:33 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,
>>
>> What would an application do when it wants to use say,
>> ManagedExecutorService, but is not implemented by a container?
>>
>> Regards,
>> Anthony
>>
>> On 7/26/12 8:29 AM, 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_ <mailto:frowe_at_us.ibm.com>
>>
>> *Anthony Lai **_<anthony.lai_at_oracle.com>_*
>> <mailto: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_
>> <mailto: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
>>
>>
>>
>