sailfin
  1. sailfin
  2. SAILFIN-1766

Null Sip Session turns for a CHS and SAS for ~37 http requests

    Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Minor Minor
    • Resolution: Cannot Reproduce
    • Affects Version/s: 2.0
    • Fix Version/s: milestone 1
    • Component/s: session_replication
    • Labels:
      None
    • Environment:

      Operating System: Linux
      Platform: Other

      Description

      Parent Issue: 1379

      SailFin Build - 13

      TimeLine:
      ~ 2009-05-08T10:50:00 - Traffic started.
      2009-05-08T11:28:35 - FAILURE_EVENT for instance110
      2009-05-08T12:13:26 - JOINED_AND_READY for instance110 (after it was restarted)

      For ~37 of the http requests (processing the second page of the app), the CHS
      and the SAS are found but SS turns up null. Below is a message in the log (from
      the app) that indicates this.

      [#|2009-05-08T12:20:53.854+0530|SEVERE|sun-glassfish-comms-server1.5|Conference|_ThreadID=28;_ThreadName=httpSSLWorkerThread-38080-6;_RequestID=7e1d1c45-4f99-4a32-b084-65927dd75c04;|ERROR:
      Exception processing the following request, page = second , sasKey =
      conf7000_568909, sessionID = ef9de63b802bc5b841fdf6b6f745
      java.io.IOException: processSecondPage: SS for ssId -
      8a55d0dc74d11952471fbfa091ab35eee665##10.12.152.19 unexpectedly null for SASKey

      • conf7000_568909
        at
        com.sun.asqe.systemtest.conference.http.ConferenceHTTPServlet.processSecondPage(ConferenceHTTPServlet.java:151)
        at
        com.sun.asqe.systemtest.conference.http.ConferenceHTTPServlet.processRequest(ConferenceHTTPServlet.java:38)
        at
        com.sun.asqe.systemtest.conference.http.ConferenceHTTPServlet.doPost(ConferenceHTTPServlet.java:264)
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:754)
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:847)
        at
        org.apache.catalina.core.ApplicationFilterChain.servletService(ApplicationFilterChain.java:427)
        at
        org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:315)
        at
        org.apache.catalina.core.StandardContextValve.invokeInternal(StandardContextValve.java:287)
        at
        org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:218)
        at
        org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:648)
        at
        org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:593)
        at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:94)
        at
        com.sun.enterprise.web.PESessionLockingStandardPipeline.invoke(PESessionLockingStandardPipeline.java:98)
        at
        com.sun.enterprise.ee.web.sessmgmt.SessionLockingStandardPipeline.invoke(SessionLockingStandardPipeline.java:120)
        at
        org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:222)
        at
        org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:648)
        at
        org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:593)
        at
        org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:587)
        at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:1096)
        at
        org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:166)
        at
        org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:648)
        at
        org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:593)
        at
        org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:587)
        at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:1096)
        at org.apache.coyote.tomcat5.CoyoteAdapter.service(CoyoteAdapter.java:290)
        at
        com.sun.enterprise.web.connector.grizzly.DefaultProcessorTask.invokeAdapter(DefaultProcessorTask.java:666)
        at
        com.sun.enterprise.web.connector.grizzly.DefaultProcessorTask.doProcess(DefaultProcessorTask.java:597)
        at
        com.sun.enterprise.web.connector.grizzly.DefaultProcessorTask.process(DefaultProcessorTask.java:871)
        at
        com.sun.enterprise.web.connector.grizzly.DefaultReadTask.executeProcessorTask(DefaultReadTask.java:341)
        at
        com.sun.enterprise.web.connector.grizzly.DefaultReadTask.doTask(DefaultReadTask.java:263)
        at
        com.sun.enterprise.web.connector.grizzly.DefaultReadTask.doTask(DefaultReadTask.java:214)
        at
        org.jvnet.glassfish.comms.clb.proxy.portunif.ClbProxyPipeline$PUTask.doTask(ClbProxyPipeline.java:532)
        at com.sun.enterprise.web.connector.grizzly.TaskBase.run(TaskBase.java:265)
        at
        com.sun.enterprise.web.connector.grizzly.ssl.SSLWorkerThread.run(SSLWorkerThread.java:106)
        #]

        Issue Links

          Activity

          Hide
          varunrupela added a comment -

          Created an attachment (id=1013)
          attached the logs from the failed and then restarted instance

          Show
          varunrupela added a comment - Created an attachment (id=1013) attached the logs from the failed and then restarted instance
          Hide
          varunrupela added a comment -

          added keyword and dependency

          Show
          varunrupela added a comment - added keyword and dependency
          Hide
          Scott Oaks added a comment -

          There are multiple possible causes for this. But it is important to note that 37
          errors is within the acceptable range for this test.

          We have observed this issue in relationship to the timings used by the test
          drivers; when the sipp driver delays too long, it misses the HTTP request, and
          the corresponding requests can get out of sync. We need to pursue a unified
          driver (or at least better communications between the existing drivers such that
          they don't get out of sync).

          Also, after the failure we will expect some losses from the async session
          replication (and the fact the logs show this happening around 6.5 minutes after
          the failure leads me to believe that's the case for most of these, because of
          the 6 minute timeout in the http driver).

          I will keep this open for now to watch in the next test cycle, but it is likely
          not a bug.

          Show
          Scott Oaks added a comment - There are multiple possible causes for this. But it is important to note that 37 errors is within the acceptable range for this test. We have observed this issue in relationship to the timings used by the test drivers; when the sipp driver delays too long, it misses the HTTP request, and the corresponding requests can get out of sync. We need to pursue a unified driver (or at least better communications between the existing drivers such that they don't get out of sync). Also, after the failure we will expect some losses from the async session replication (and the fact the logs show this happening around 6.5 minutes after the failure leads me to believe that's the case for most of these, because of the 6 minute timeout in the http driver). I will keep this open for now to watch in the next test cycle, but it is likely not a bug.
          Hide
          Scott Oaks added a comment -

          Sony and I have had discussions about the need to pursue a unified driver, but
          no one has had cycles to work on it. Between the driver syncing and the range of
          errors (given the async replication), I'm lowering the priority of this.

          Show
          Scott Oaks added a comment - Sony and I have had discussions about the need to pursue a unified driver, but no one has had cycles to work on it. Between the driver syncing and the range of errors (given the async replication), I'm lowering the priority of this.
          Hide
          varunrupela added a comment -

          Not seeing this issue with build 31b 15th nightly. Closing the issue.

          Show
          varunrupela added a comment - Not seeing this issue with build 31b 15th nightly. Closing the issue.

            People

            • Assignee:
              Mahesh Kannan
              Reporter:
              varunrupela
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: