Hi Fred,
Thanks for the reminder on TCK.
Is there a reason to define a single default jndi name?
It can be left to the product vendor to define based
on some configuration attribute, right? As long as vendor
has the ability to expose such an executor service, it
should be okay?
thanks,
Binod.
On Saturday 02 March 2013 02:40 AM, Frederick W Rowe wrote:
> Binod,
>
> We've discussed the SIP requirements you brought up with the IBM EG member
> and we're ok with the proposal for SIP to use a JSR236
> ManagedExecutorSerivce assuming there is only one instance of SIP specific
> managed executor service (you should probably discuss and choose a default
> instance name for jndi registration in the SIP EG).
> You should also discuss and standardize a SIP specific execution property
> used to indicate the need to limit access to a SIP session by a single
> thread with the understanding that property is specific to the SIP
> ManagedExecutorSerivce and would only be honored by it.
> One reminder, in choosing to do this, it will assume compliance of the
> SIP-specific ManagedExecutorService with the JSR236 spec and thus the
> ability to pass the associated TCK.
>
> Regards,
>
> Fred Rowe
>
> WebSphere Architect
> Senior Software Engineer
> IBM Software Group
>
>
>
> Binod <binod.pg_at_oracle.com>
> 02/21/2013 11:35 AM
> Please respond to
> jsr236-experts
>
>
> To
> jsr236-experts_at_concurrency-ee-spec.java.net
> cc
>
> Subject
> [jsr236-experts] Re: New ContextService API proposal from JSR 359 spec
> lead
>
>
>
>
>
>
> Hi Anthony,
>
> Sorry for the delay. I was discussing with SIP Servlet EG on the
> possibilities.
>
> One way to handle the concurrency issue is by using the thread pool
> of the SIP Servlet Container to run the tasks. So, if the SIP Servlet spec
> defines that a JSR 236 ManagedExecutorService
> (and a ManagedScheduledExecutorService) will be made available to
> the SIP Servlet applications (using the standard JSR 236 lookup mechanism)
> and the submitted tasks will be executed by SIP Servlet Container using
> its thread pool, then the concurrency can be handled by the SIP container.
>
> The question is, whether this is okay from a JSR 236 spec perspective?
>
> If it is okay, SIP Servlet Spec will specify some way to pass the correct
> sip application session contexts to the container/task. It may be done
> by passing sip application session id (not the session itself) in the
> context
> service properties.
>
> thanks,
> Binod.
>
> On Monday 18 February 2013 11:09 PM, Anthony Lai wrote:
>> Hi Binod,
>>> Or do you expect all the tasks to be executed
>>> by an executor which is mostly independent of individual technology
>>> containers?
>> From JSR 236 standpoint, a task is simply a Runnable or Callable with
>> some context setup requirements. Perhaps I did not fully understand
>> your question. Could you please clarify?
>>
>> Regards
>> Anthony
>>
>> On 2/15/13 2:38 AM, Binod wrote:
>>> On Thursday 14 February 2013 10:51 PM, David M. Lloyd wrote:
>>>> On 02/14/2013 09:44 AM, Binod wrote:
>>>>> On Tuesday 12 February 2013 06:25 PM, frowe_at_us.ibm.com wrote:
>>>>>> I agree with David that unless there is some other usercase which
>>>>>> cannot be addressed by storing info (like ContextHints) on the
>>>>>> Runnable, the additional API is not necessary.
>>>>> I think, the usecase has come down to the following question.
>>>>>
>>>>> When a task is submitted, is it possible for ManagedExecutorService
>>>>> to handover the task to a container (eg: SIP container) for executing
>>>>> the task?
>>>>>
>>>>> The container may choose to enforce certain locking semantics based
> on
>>>>> some additional contextual information (like the
>>>>> SipApplicationSession)
>>>>>
>>>>> What would be the recommendation from
>>>>> this EG for achieving the same?
>>>> I think what you're describing is the need for a generalized API for
>>>> capturing and mutating execution context, and then selectively
>>>> propagating some or all of that context to a managed executor so
>>>> that container services have access to it?
>>>>
>>>> This is a tricky problem, but I think that wrapping Runnables with
>>>> proxies probably isn't the right solution (it would only be useful
>>>> in cases where the one who is instantiating and/or submitting the
>>>> task is aware of what context needs to be propagated). Consider
>>>> container-managed context like transactions, security, and component
>>>> association, and any other container-specific context or
>>>> framework-specific context.
>>> In the usecase we have with SIP Servlets, the one (sip servlet app)
>>> who instantiates and submit the
>>> task is aware of the context that need to be propagated to its
>>> container. It is difficult for the container
>>> alone to find the right context.
>>>
>>> Lets say that SIP Servlets figure out a mechanism for the application
>>> to specify such a context,
>>> would a SIP Servlet Container be able to run the task which has that
>>> context, with appropriate locking?
>>> Is that sensible from the point of view of JSR 236? Or do you expect
>>> all the tasks to be executed
>>> by an executor which is mostly independent of individual technology
>>> containers?
>>>
>>> If you folks think that it is okay for SIP Servlet specification to
>>> leverage JSR 236 for this purpose,
>>> then how SIP container work with JSR 236 implementation in an
>>> application server, to achieve the same
>>> gets reduced to a question about implementation.
>>>
>>> thanks,
>>> Binod.
>>>> A good solution to this problem would have the following
>>>> characteristics (and probably many others as well):
>>>>
>>>> * The container and user components would be able to use the same
>>>> mechanism
>>>> * The task creator or submitter would not have to directly worry
>>>> about choosing what context to propagate
>>>> * Any party which defines or uses a propagated context type should
>>>> be isolated from other parties who do so (i.e. users should not be
>>>> able to tamper with component-defined context)
>>>> * All cross-boundary invocations in the container should have
>>>> well-defined context propagation semantics
>>>> * Relatedly, all defined context types should define how/if they are
>>>> propagated across cross-boundary invocations of various color
>>>>
>
>