3 Replies Latest reply: Feb 16, 2010 12:47 PM by user753546 RSS

    Is SipSession Serializable?

    715547
      In a Session Attribute i store a DialogState Object which in turn has the SipSession as a private class member. sometimes OCCAS throws a Nullpointer exception on my DialogState Object where m_SipSession.hashCode() is used as the DialogState hashcode().
      The SipSession member i declared as:

      private final SipSession m_Session;

      and always set on the constructor of the DialogState object.

      Now the stack trace (see below) is what i get sometimes. It doesnt involve my app and seems to relate to some form of deserialization (i guess for state replication).
      So question is why this exception? is SipSession serializable or do i need to do something else here?

      at com.siplib.dialogcontrol.DialogState.hashCode(DialogState.java:848)
      at java.util.HashMap.putForCreate(HashMap.java:413)
      at java.util.HashMap.readObject(HashMap.java:1031)
      at sun.reflect.GeneratedMethodAccessor1.invoke(Unknown Source)
      at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
      at java.lang.reflect.Method.invoke(Method.java:597)
      at java.io.ObjectStreamClass.invokeReadObject(ObjectStreamClass.java:974)
      at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1849)
      at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
      at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
      at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)
      at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)
      at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
      at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
      at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)
      at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)
      at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
      at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
      at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)
      at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)
      at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
      at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
      at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
      at java.util.HashMap.readObject(HashMap.java:1030)
      at sun.reflect.GeneratedMethodAccessor1.invoke(Unknown Source)
      at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
      at java.lang.reflect.Method.invoke(Method.java:597)
      at java.io.ObjectStreamClass.invokeReadObject(ObjectStreamClass.java:974)
      at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1849)
      at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
      at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
      at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)
      at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)
      at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
      at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
      at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
      at java.util.HashMap.readObject(HashMap.java:1030)
      at sun.reflect.GeneratedMethodAccessor1.invoke(Unknown Source)
      at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
      at java.lang.reflect.Method.invoke(Method.java:597)
      at java.io.ObjectStreamClass.invokeReadObject(ObjectStreamClass.java:974)
      at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1849)
      at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
      at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
      at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)
      at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)
      at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
      at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
      at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
      at com.bea.wcp.sip.engine.server.CallState.readObject(CallState.java:852)
      at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
      at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
      at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
      at java.lang.reflect.Method.invoke(Method.java:597)
      at java.io.ObjectStreamClass.invokeReadObject(ObjectStreamClass.java:974)
      at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1849)
      at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
      at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
      at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
      at com.bea.wcp.sip.engine.server.LocalCallStateManager$CallStateTask.bytesToCallState(LocalCallStateManager.java:361)
      at com.bea.wcp.sip.engine.server.LocalCallStateManager$CallStateTask.restoreCallState(LocalCallStateManager.java:369)
      at com.bea.wcp.sip.engine.server.LocalCallStateManager.lockAndGetCallState(LocalCallStateManager.java:85)
      at com.bea.wcp.sip.engine.server.MessageHandler$MessageQueue.processMessages(MessageHandler.java:562)
      at com.bea.wcp.sip.engine.server.MessageHandler$MessageQueue.processMessages(MessageHandler.java:523)
      at com.bea.wcp.sip.engine.server.MessageHandler$MessageQueue.checkMessages(MessageHandler.java:487)
      at com.bea.wcp.sip.engine.server.MessageHandler$MessageQueue.addMessage(MessageHandler.java:463)
      at com.bea.wcp.sip.engine.server.MessageHandler.receiveMessage(MessageHandler.java:259)
      at com.bea.wcp.sip.engine.connector.transport.AbstractTransport.dispatchOrFwdSidewaysMsg(AbstractTransport.java:175)
      at com.bea.wcp.sip.engine.connector.transport.AbstractTransport.dispatch(AbstractTransport.java:157)
      at com.bea.wcp.sip.engine.connector.transport.UdpTransportModule$UdpWorker.run(UdpTransportModule.java:750)
      at weblogic.work.SelfTuningWorkManagerImpl$WorkAdapterImpl.run(SelfTuningWorkManagerImpl.java:516)
      at weblogic.work.ExecuteThread.execute(ExecuteThread.java:201)
      at weblogic.work.ExecuteThread.run(ExecuteThread.java:173)
        • 1. Re: Is SipSession Serializable?
          738432
          Sorry to not answer the question directly, but I wonder why you are storing the SipSession at all? You can always get the SipSession associated with a received message via SipServletMessage.getSession(). If you need a different SipSession, you can find all SipSessions within a SipApplicationSession.getSessions(). Or use B2buaHelper. Can you say more about your application requirements?
          • 2. Re: Is SipSession Serializable?
            715547
            The scenario i'm having is a B2BUA where i have multiple parallel outbound legs (parallel forking) which could also cause "early dialogs" and therefore it is getting challenging to link sessions with B2BUAHelper. So i'm creating my own B2BUA class. also am not sure whether the session linking would work if inbound and outbound SipSessions are on different SipApplicationSessions.

            In any case, storing SipSessions without the B2BUAHelper should be possible. In JSR289 section 12.3.1 Explicit Session Linkage it notes:

            <JSR289>
            Note that 1-1 linking is a convenience function and in no way mandatory for B2BUA functionality, in other words, the old style B2BUAs using just v1.0 API, where the peer session/request was stored as attributes, are also supported without any change.
            </JSR289>

            So storing SipSessions as attributes should be feasible amd therefore I was assuming that SipSession is serializable.

            Is this not the case?
            • 3. Re: Is SipSession Serializable?
              user753546
              It seems like you are using standalone domain here. By default local replication is enabled for standalone domain in OCCAS4.0 and the issue seems to happen while de-serialization of your object happens. Session is serializable and I believe should be available ( unless you have custom readObject implemented in your code for dialog object and something went wrong there or somehow session was invalid).

              This is what I'd suggest
              Use
              -Dwlss.local.serialization=false system property when you start your standalone domain server and see if issue is resolved, wlss.local.serialization is true by default.

              If setting above property works then for your case i.e wlss.local.serialization being true please work with oracle support and create a bug so that it can be looked into .
              Provide them server and stdout logs with following debug flags
              -Dwlss.SipSession=true
              -Dwlss.Transaction=true
              It will be great if you can provide a reproducer also .


              FYI In general

              The standalone domain can be either optimized for performance or memory based on the application need.

              Optimization for heap/memory (-Dwlss.local.serialization=true case [default])
              -------------------------------------------------------------------
              1. This holds good if memory utilization is a concern
              2. Call hold times are large and hence hence callstate keeps sitting in the
              memory for the lifetime of call.

              In this optimization the the callstate is serialized as soon as dialog is
              established and is de-serialized as and when it is required for any
              subsequent call handling. This way the callstate doesnot always sit in memory
              . But it does have performance impact as there is a overhead in
              serializing-deserializing the callstate as well as synchronization for thread
              safety where ever applicable.



              Optimization for Performance (-Dwlss.local.serialization=false case)
              -------------------------------------------------------------------
              1. This hold good if thruput is the prime concern.
              2. Here callstate is not serialized/de-serialized and is suitable for
              application which have
              a) Less call hold times
              b) Low values of application session timeout
              c) A callstate gets used very frequently

              In this optimization callstate is kept in memory for the life of the call.
              But if call hold times or call life time is large then it will end up in
              utilizing most of heap space. There is a performance gain here as callstate
              is not serialized/de-serialized and even less synchronization. This has been
              default case in wlss3.0/wlss3.1 as there is no concept of local
              serialization.

              If your case is performance sensitive then -Dwlss.local.serialization=false is right choice for you.

              Hope it helps.

              Regards
              Anurag Bahl