sailfin
  1. sailfin
  2. SAILFIN-1820

subscribe-refresh, an instance kill, got OOM.

    Details

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

      Operating System: All
      Platform: All

    • Issuezilla Id:
      1,820

      Description

      ********************************************************************************

      • Template v0.1 ( 05/01/08 )
      • Sailfin Stress test issue
        ********************************************************************************

      Sailfin Build : 10
      Cluster size : 10
      Happens in a single instance (y/n) ? : NA
      Test id : st2_4_presence_subscribe-refresh
      Location of the test : as-telco-sqe/stress-ws/presence
      JDK version : 1.6.0_14
      CLB used : Yes
      HW LB used : No.
      SSR: Enabled
      =========================================================

      I've run subscribe-refresh scenario on 10 SuSE machines, with b19 and JDK
      1.6.0_14 64 bits. Was used a loading 300K/275 cps, ssr was enabled. The run
      was going on during about 22 hours without any problems until an instance was
      killed. After that during 30 minutes was reached Full gc and then OOM. When
      I've run the same scenario on the same machines, with the same setting and with
      a loading 200k/275 cps, the run was OK.
      See all logs for the run against b19 at http://agni-1.sfbay.sun.com/net/asqe-
      logs/export1/SailFin/Results/sfbuild19/sbr_kill1/

      I've attached excel file with time/heap numbers for one instance (instance9),
      I've marked there a time when an instance (instance5) was killded

        Activity

        Hide
        easarina added a comment -

        Created an attachment (id=1036)
        excel file, that represent time/heap size

        Show
        easarina added a comment - Created an attachment (id=1036) excel file, that represent time/heap size
        Hide
        easarina added a comment -

        I've re-run this test on SuSE machines, using b20 with two patches: 1827 patch
        and jxta 1727 patch. Was used a loading -r 300 -m 222222. After an instance was
        killed one time, the memory was stable. See logs under:
        http://agni-1.sfbay.sun.com/net/asqe-logs/export1/SailFin/Results/sfbuild20/sbrf_r2/

        So I believe this issue was fixed.

        Show
        easarina added a comment - I've re-run this test on SuSE machines, using b20 with two patches: 1827 patch and jxta 1727 patch. Was used a loading -r 300 -m 222222. After an instance was killed one time, the memory was stable. See logs under: http://agni-1.sfbay.sun.com/net/asqe-logs/export1/SailFin/Results/sfbuild20/sbrf_r2/ So I believe this issue was fixed.

          People

          • Assignee:
            Scott Oaks
            Reporter:
            easarina
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: