Skip to main content

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

  • From: Binod < >
  • To:
  • Subject: Re: [jsr236-experts] Re: New ContextService API proposal from JSR 359 spec lead
  • Date: Fri, 08 Feb 2013 18:09:24 +0530

Keith,

The reference to SipSession is only as an example to JSR 236 EG. I dont think
it reflects our discussion on concurrency.

Please see inserted for comments.

On Friday 08 February 2013 05:48 PM, Lewis, Keith wrote:
" type="cite">

I would think that we could ensure that we maintain information about the current SAS on the thread. Then if any asynchronous JSR236 facilities are invoked the information can be passed to the container and can influence the timing of thread execution. If we are to provide a SAS CDI scope we will need this information as a thread context anyway.

We can provide API support to allow the app to change the SAS. I have put forward some suggestions for this in my email about CDI and interworking, we also had some suggestion put forward at the F2F when discussing CDI. Where SAS locking is in use the change of SAS would mean releasing the lock on the current SAS and acquiring a lock on the new SAS.

I am not clear why we need any change to JSR236. Is there a more involved use case where we will not have the required information as a thread context?
If we are able to change CDI context and the get consensus on our EG, then that is great.
Otherwise, we will not have all required information as thread context.

We can let the SAS id passed to the container/runnable as a context property as Nitzan
suggested. But it could incur additional look up of SAS (potentially from a remote store)
in some cases.

" type="cite">
If the SAS inherited by a thread allocated through the JSR 236 facilities is not the one that is needed then the API method can be used to swap to a different SAS. If we want to optimise this case by not locking on the original SAS then we can use an executor property to pass a "No SAS context needed" hint. This would tell would ManagedExecutorService not to propagate the SAS context from the original thread and not to do any locking.

In the above I am assuming that the JNDI lookup of a ManagedServiceExecutor will return one that is part of the SIp container and that has the locking behaviour we define. I suppose that this will be the case for SIP apps. For converged apps I suppose that we will want to create an executor service that satisfies the requirements of BOTH the Sip and Web container. That is the case for other aspects of a converged container anyway e.g. the ServletContext.

Yes. Above everything, this is the point we need to get confirmed by JSR 236 EG.

thanks,
Binod.

" type="cite">
Keith

On Wed, Jan 30, 2013 at 4:47 AM, Binod < " target="_blank"> > wrote:
FYI. Here is where the discussion with 236 EG stand at the moment.


-------- Original Message --------
Subject: [jsr236-experts] Re: New ContextService API proposal from JSR 359 spec lead
Date: Fri, 25 Jan 2013 13:40:19 +0530
From: Binod " target="_blank">< >
Reply-To: " target="_blank">
To: " target="_blank">


The main intention of the proposal was to let the
container to know about the context, so that it can
take the correct locking decisions, though it also
gives consistent interface to retrieve the hint/session
irrespective of how the task was initiated.

The problem is user of the managed executor service
alone cannot make the application thread safe, since
the container also uses the same context object for locking.

Eg: Container invoke servlets after locking the sipappsession/session,
Container has its own timers that are executed after locking sipappsession/session.

The container also ensure the consistency when there are
multiple JVMs. So, I am afraid, it is not something we can
leave it to the application alone.

thanks,
Binod.

On Thursday 24 January 2013 10:29 PM, Nathan Rauh wrote:
Binod,

Thanks for the examples.  After reading the SipSessionUtil api and seeing the example, it seems to me that ContextService should not be needed at all for the SipSessionUtil path.
Wouldn't the following accomplish the same thing without ContextService at all?
   InitialContext ctx = new InitialContext();
 
ManagedExecutorService mes = (ManagedExecutorService)
        ctx.lookup("java:comp/env/concurrent/SipThreadPool");

   Future f = mes.submit(new Runnable() {
       public void run() {
           SipApplicationSession sas = sipsessionsutil.getApplicationSessionByKey("conference1", true);
           //Use sas to send an invite to a party in the conference or send
          //a text message.

       }
   });

And it seems the other case, SipServletRequest.getSession(), could be addressed by a SIP Session context along the lines of classloader context / security context / namespace context,
   InitialContext ctx = new InitialContext();
 
ManagedExecutorService mes = (ManagedExecutorService)
        ctx.lookup("java:comp/env/concurrent/SipThreadPool");

   Future f = mes.submit(new Runnable() {
       public void run() {
           SipApplicationSession sas = (SipApplicationSession) sipServletRequest.getSession();
           //Use sas to send an invite to a party in the conference or send
          //a text message.

       }
   });
where the container would implement sipServletRequest.getSession  to return the instance associated with the thread which can be managed by the managed executor service when propagation of SIP session context is configured for it.

I realize this doesn't address any of the locking concerns, which I see as a separate problem that ought to be solved at the level of the user of the managed executor service, who can do something like putting tasks that shouldn't run concurrently into a queue, from which tasks are submitted to the executor service one at a time, waiting for the future before submitting the next one.  In this case, ContextService is valuable in that it can capture the thread context upfront, but I'm still not convinced of any need for additions to the ContextService interface itself to acomplish what you are doing.


Nathan Rauh
____________________________________________
Software Engineer, WebSphere Application Server
IBM Rochester Bldg 002-2 C111
3605 Highway 52N
Rochester, MN 55901-7802




From:        Binod " target="_blank">< >
To:        Nathan Rauh/Rochester/IBM@IBMUS
Cc:         " target="_blank">
Date:        01/24/2013 01:18 AM
Subject:        [jsr236-experts] Re: New ContextService API proposal from JSR 359 spec lead




Hi Nathan,

There are multiple ways a SipSession or SipApplicationSession is obtained
by the application. One way is what you described (message.getSession).

The other is by finding a session using a utility provided by container.

http://docs.oracle.com/cd/E13209_01/wlcp/wlss40/javadoc/jsr289/javax/servlet/sip/SipSessionsUtil.html

So, it is possible that a thread might fetch more than one SipSession or
SipApplicationSession.

In short, the container cannot figure out which session will be used by
application. So it is different from classloader context.

public class MyRunnable implements Runnable {
   public void run() {
       System.out.println("MyRunnable.run with Container Context available.");            
         ContextService ctxService = (ContextService) ctx
        .lookup("java:comp/env/concurrent/SipContextService");
        SipApplicationSession sas  = ctxService.getContextHint(this).getHint();

        //Use sas to send an invite to a party in the conference or send
        //a text message.
    }
}

public void amethod_in_siporhttp_servlet() {
  InitialContext ctx = new InitialContext();
 
ManagedExecutorService mes = (ManagedExecutorService)
        ctx.lookup("java:comp/env/concurrent/SipThreadPool");
       
  ContextService ctxService = (ContextService) ctx
        .lookup("java:comp/env/concurrent/SipContextService");

  MyRunnable myRunnableInstance = ...;

  //Find the sipapplicationsession of a conference.
  SipApplicationSession sas = sipsessionsutil.getApplicationSessionByKey("conference1", true);
  ContextHint<SipApplicationSession> hint = new MyContextHint<SipApplicationSession>(sas);
  Runnable rProxy = ctxService.createContextualProxy(myRunnableInstance, Runnable.class, hint);

  Future f = mes.submit(rProxy);

}

If you look at the code above, the application (essentially a method in a sipservlet
or even httpservlet) is looking up a SipApplicationSession belonging to a conference
and submit a task. The task when it is executed, might make an outgoing call or send
a notification message or play an announcement etc.

Besides SIP context, the proxy should have the same usual java ee contexts (JNDI, ClassLoader
and security).

Let me know of any more questions..

thanks,
Binod.

On Thursday 24 January 2013 01:23 AM, Nathan Rauh wrote:

I'm re-sending my email because it seems I forgot to copy Binod.



From:        
Nathan Rauh/Rochester/IBM
To:        
" target="_blank">
Date:        
01/23/2013 01:50 PM
Subject:        
Re: [jsr236-experts] Re: New ContextService API proposal from JSR 359 spec lead



Binod,


When you state "
The ContextHint is a way for the application to provide a hint to the container about the task execution strategy"  -- that's exactly what execution properties are intended for.  So I want to ensure that we are making execution properties flexible enough to achieve what you are trying to do here, and that we don't add a duplicate mechanism that does essentially the same thing.
I also want to make sure that hints/properties supplied to ContextService is really the best way to go about solving the problem you are trying to address.


Could you provide some specific scenarios showing how SIP would take advantage of ContextService, including who is invoking these operations on ContextService, and where they get the SipSession/SipApplicationSession from, and what it is needing to run with context, and which other context (if any) besides SIP should be available to the contextual proxy, and how it will use the SipSession/SipApplicationSession that are being propagated to it?


Without knowing very much about SIP, I have to wonder if there ought to be a type of thread context for SIP session along the lines of security, classloader, or naming, where context propagation can be done more automatically by the container.

For example, with classloader context, the application doesn't need to set its own classloader into the execution properties.  The container just automatically makes sure the contextual task runs with the class loader of the application that created the contextual proxy.   So I'd like to ask if a similar model makes sense here.   Is the SipSession/SipApplicationSession already present in some way on the thread where ContextService.createContextualProxy is requested from?  And does the code that's being contextualized have some way of accessing the session or session info from the thread?  If I go looking through the APIs, I see a SipServletRequest.getSession() method that seems to return the session.  Is the goal here just to make SipServletRequest.getSession() or other methods like it return the correct session when running from the contextual proxy?



Nathan Rauh
____________________________________________
Software Engineer, WebSphere Application Server
IBM Rochester Bldg 002-2 C111
3605 Highway 52N
Rochester, MN 55901-7802





From:        
Binod " target="_blank">< >
To:        
Nathan Rauh/Rochester/IBM@IBMUS
Cc:        
" target="_blank">
Date:        
01/22/2013 09:48 PM
Subject:        
[jsr236-experts] Re: New ContextService API proposal from JSR 359 spec lead





The case we (JSR 359 EG) have is not "only" to pass a contextual information
from application to the task/callable/runnable. The ContextHint is a way for
the application to provide a hint to the container about the task execution strategy.

Specifically, the
ContainerSpecificContextObject can be a "SipSession" or a
"SipApplicationSession". When the container receives this object as
the hint, it should select a locking strategy such that there is no
concurrent execution of tasks for that
ContainerSpecificContextObject.

So, for the usecases, we have been thinking about, the ContextHint may
not be serializable and the lifecycle management of the ContextHint is
upto the specific container that know about it.

BTW, ContextHint mechanism is just a suggestion. I am open to any
mechanism that help us utilizing JSR 236.

thanks,
Binod.

On Wednesday 23 January 2013 01:30 AM, Nathan Rauh wrote:

Anthony/Binod,


I'm not sure I see the need for a new method that adds a ContextHint capability.  Execution properties should already allow for this, apart from the requirement that execution properties always be String values whereas the ContextHint in the example has some other custom type (
ContainerSpecificContextObject).

Here's an example with the existing ContextService interfaces,


Map<String, String> hints = Collections.singletonMap("com.mycompany.hints.MY_HINT_1", hint);
Runnable rProxy = ctxService.createContextualProxy(myRunnableInstance, hints, Runnable.class);
Future f = execSvc.submit(rProxy);


...

hint = ctxService.getExecutionProperties(myRunnableInstance).get("com.mycompany.hints.MY_HINT_1");


I would be open to allowing data types other than String from execution properties, provided those other types are serializable types defined in Java SE and deserializable from any classloader.  But I'm hesitant to allow just any type to be stored as an execution property (or ContextHint) because contextual proxies must be able to serialize/deserialize properly, which means knowing the correct classloader of everything that serializes along with it.


So I'm curious to learn more about what the "
ContainerSpecificContextObject" is.

Nathan Rauh
____________________________________________
Software Engineer, WebSphere Application Server
IBM Rochester Bldg 002-2 C111
3605 Highway 52N
Rochester, MN 55901-7802




From:        
Anthony Lai " target="_blank">< >
To:        
" target="_blank">
Cc:        
Binod " target="_blank">< >
Date:        
01/22/2013 01:07 PM
Subject:        
[jsr236-experts] New ContextService API proposal from JSR 359 spec lead




Dear Experts,

Binod, the spec lead for JSR 359 - SIP Servlet 2.0, is proposing a new API in ContextService to pass in application-provided information that can be retrieved in the thread that executes the task.

Forwarding Binod's suggestion:

<quote>
It is possible for some containers to build contextual object based
on application provided information. For example, a container could support
thread safe execution of the tasks based on a specific contextual
information.


   <T> T
createContextualProxy(T instance, Properties executionProperties, Class<T> intf, ContextHint<C> hint)
   
Object getContextHint(Object contextObject)  
    /** Context hint information that contains the container specific object. **/
   interface ContextHint<C> {
       void setHint(C hint);
       C getHint();
   }


Example code:


public class MyRunnable implements Runnable {
   public void run() {
       System.out.println("MyRunnable.run with Container Context available.");            
         ContextService ctxService = (ContextService) ctx
        .lookup("java:comp/env/concurrent/ContainerSpecificContextService");
        ContainerSpecificContextObject object  = ctxService.getContextHint(this);

    }
}

InitialContext ctx = new InitialContext();
ManagedExecutorService mes = (ManagedExecutorService)
        ctx.lookup("java:comp/env/concurrent/ContainerThreadPool");
       
ContextService ctxService = (ContextService) ctx
        .lookup("java:comp/env/concurrent/ContainerSpecificContextService");

MyRunnable myRunnableInstance = ...;

ContextHint<ContainerSpecificContextObject> hint = new MyContextHint<ContainerSpecificContextObject>(...);
Runnable rProxy = ctxService.createContextualProxy(myRunnableInstance, Runnable.class, hint);

Future f = mes.submit(rProxy);

</unquote>

Any comments are welcome.

Regards
Anthony









 
--------------------
Note: The information contained in this message may be privileged and confidential 
and protected from disclosure. If the reader of this message is not the intended 
recipient, or an employee or agent responsible for delivering this message to the 
intended recipient, you are hereby notified that any dissemination, distribution or 
copying of this communication is strictly prohibited. If you have received this 
communication in error, please notify us immediately by replying to the message and 
deleting it from your computer. Thank you. Thrupoint, Inc.






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

Nitzan Nissim 02/06/2013

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

Binod 02/07/2013

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

Lewis, Keith 02/08/2013

<Possible follow-up(s)>

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

Lewis, Keith 02/08/2013

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

Binod 02/08/2013

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

Binod 02/28/2013
 
 
Close
loading
Please Confirm
Close