1 Reply Latest reply: Jun 29, 2011 8:41 AM by Kai-Oracle RSS

    com.bea.wcp.sip.engine.server.UnableToLockException

    638174
      Hi,

      I am getting the following error thrown from some engine tier nodes and was hoping that someone could explain what the problems is:


      com.bea.wcp.sip.engine.server.UnableToLockException: Could not lock call state even after waiting for more than 5000 ms
      at com.bea.wcp.sip.engine.server.CallStateManager.enter(CallStateManager.java:220)
      at com.bea.wcp.sip.engine.SipSessionsUtilAdapter.getApplicationSessionById(SipSessionsUtilAdapter.java:135)
      <snip>
      Caused by: com.bea.wcp.sip.engine.server.LockTimeoutException: Could not lock call state 5d38aaf251074e0127c9ecbc045e6c18@192.168.46.26 even after waiting for more than 5000 ms
      at com.bea.wcp.sip.engine.server.CallStateManager.doLockAndGet(CallStateManager.java:280)
      at com.bea.wcp.sip.engine.server.CallStateManager.enter(CallStateManager.java:250)
      at com.bea.wcp.sip.engine.server.CallStateManager.enter(CallStateManager.java:217)
      ... 52 more

      Do I need to be doing explicit lock/unlocking of a session or suchlike? I imagined that the container would take care of all that for me?

      Thanks in advance
      Huw
        • 1. Re: com.bea.wcp.sip.engine.server.UnableToLockException
          Kai-Oracle
          Hello,

          1. Before a servlet's doXX() method is entered, the call state (basically the application session and all SIP and HTTP sessions belonging to it) is locked so that only one thread can access it at one time.

          2. So there is another doXXX() method or SIP timer that look the session for more than 5 seconds. Maybe there is some not sip related code inside the method such as DB calls that makes the execution of the method too slow. Thread dumps might show this.

          3. OCCAS 5.0 introduces its own API for avoiding session locking and if an application knows what it does it can access the session asynchronous as well. So when you can't move the blocking work to a place where no sip session access is needed such as delegating to a JMS listener, you might like to define an WlssAsynchronousAction that does not block the session.

          SipApplicationSession appSession = ...;
          WlssSipApplicationSession wlssAppSession = (WlssSipApplicationSession) appSession;

          wlssAppSession.doAsynchronousAction(new WlssAsynchronousAction() {
          public Object run() throws Exception {

          // add your business logic here
          appSession.setAttribute("counter", latestCounterValue);
          sipSession.setAttribute("currentState", latestAppState);

          return null;
          }
          });



          See: http://download.oracle.com/docs/cd/E17645_01/doc.50/e18767/html/com/bea/wcp/sip/WlssSipApplicationSession.html

          IMPORTANT: But still the first step should be to avoid long running code in a SIP doXX() or timer method.

          Best regards,
          Kai

          _____________________________
          To reach a wider audience for your question please consider posting on
          the My Oracle Support forum
          https://communities.oracle.com/portal/server.pt/community/service_delivery_platform.
          _____________________________