As far as I can tell, the JSR 236 spec does not prevent defining such
special purpose ManagedExecutorService.
Does anyone see any issues with Binod's approach?
Regards
Anthony
On 2/21/13 8:35 AM, Binod wrote:
> 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
>>>>
>>>
>>
>