Skip to main content

Fwd: [jsr236-experts] Re: New ContextService API proposal from JSR 359 spec lead

  • From: Binod < >
  • To:
  • Subject: Fwd: [jsr236-experts] Re: New ContextService API proposal from JSR 359 spec lead
  • Date: Thu, 28 Feb 2013 12:26:46 +0530
  • List-id: <jsr359-experts.sipservlet-spec.java.net>




-------- Original Message --------
Subject: [jsr236-experts] Re: New ContextService API proposal from JSR 359 spec lead
Date: Thu, 21 Feb 2013 16:00:51 -0800
From: Anthony Lai ">< >
Reply-To: ">
To: ">


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, 
      
      ">
       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
>>>>
>>>
>>
>





Fwd: [jsr236-experts] Re: New ContextService API proposal from JSR 359 spec lead

Binod 02/28/2013
 
 
Close
loading
Please Confirm
Close