Skip to main content

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

  • From: Nitzan Nissim < >
  • To:
  • Subject: Re: Fwd: [jsr236-experts] Re: New ContextService API proposal from JSR 359 spec lead
  • Date: Wed, 6 Feb 2013 18:42:45 +0200

Binod, as far as I understand the use of the context execution properties
from Nathan's suggestion, it does seem like possible way to achieve what we
are trying to do.

JSR 359 can define a const execution property name, like
"SAS_KEY_EXECUTION_HINT", "SAS_ID_EXECUTION_HINT" or something like that,
and the app composer will populate the properties map with the key/id as
values.

The SIP containers can get that property (by calling: String sasID =
ctxService.getExecutionProperties(myRunnableInstance).get("
SAS_ID_EXECUTION_HINT");) and use it to find the session and execute the
runnable with the proper locking/order.

Does that makes sense, or am I missing something here?


What that I am not sure about, is the ManagedExecutorService.
It inherits methods from ExecutorService like shutDown() and shutdownNow(),
and I don't think we want to give the application such control over the
container execution. Otherwise, we will have to define what shutting down
the executor service means for the SIP container (it shouldn't affect any
other aplication tasks or other application session tasks)

Thanks,
Nitzan

_______________________________________________
Nitzan Nissim
SIP Container Architect, WebSphere SIP Infrastructure
IBM Software Group, AIM
Israel Software Lab
+972 (54) 6976107
+972 (8) 9482326







From:   Binod 
< >
To:     
,
Date:   30/01/2013 06:47 AM
Subject:        Fwd: [jsr236-experts] Re: New ContextService API proposal from
            JSR 359 spec lead



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 
< >
                                   
                                                                         
 Reply-To: 

                   
                                                                         
                                                                         
       To: 

                   
                                                                         



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 
< >
      To:        Nathan Rauh/Rochester/IBM@IBMUS
      Cc:        

      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:        

      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 
< >
      To:        Nathan Rauh/Rochester/IBM@IBMUS
      Cc:        

      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 
< >
      To:        

      Cc:        Binod 
< >
      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











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