Qpid
  1. Qpid
  2. QPID-3794

Test StatisticsCounterTest.testPeakOutOfOrder fails sporadically on test profile java-mms-spawn.0-10

    Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 0.15
    • Fix Version/s: None
    • Component/s: Java Tests
    • Labels:
      None

      Description

      Test StatisticsCounterTest.testPeakOutOfOrder fails sporadically on test profile java-mms-spawn.0-10

      junit.framework.AssertionFailedError: expected:<0.0> but was:<3000.0>
      at org.apache.qpid.server.stats.StatisticsCounterTest.testPeakOutOfOrder(StatisticsCounterTest.java:110)

        Activity

        Alex Rudyy created issue -
        Alex Rudyy made changes -
        Field Original Value New Value
        Assignee Alex Rudyy [ alex.rufous ]
        Alex Rudyy made changes -
        Status Open [ 1 ] In Progress [ 3 ]
        Hide
        Alex Rudyy added a comment -

        Attached a patch with a potential problem fix.

        I could not reproduce the issue locally.

        I believe that the only reason why this test failed is that the sequential invocations of Thread.sleep() caused current thread to sleep for more time than it was expected.

        Thread.sleep(1500);
        Thread.sleep(1000);

        The total expected sleeping interval is 2500 mls.

        It seems that for failed test the thread slept for more than 3000+ mls in total during first 2 sleep invocations and as result of it the counter peak value was evaluated due to finishing the sample period which is 1 second.

        It seems that thread overslept for more than 500mls which is quite unexpected value. Perhaps, extra GC activity caused it. I am not sure.

        Show
        Alex Rudyy added a comment - Attached a patch with a potential problem fix. I could not reproduce the issue locally. I believe that the only reason why this test failed is that the sequential invocations of Thread.sleep() caused current thread to sleep for more time than it was expected. Thread.sleep(1500); Thread.sleep(1000); The total expected sleeping interval is 2500 mls. It seems that for failed test the thread slept for more than 3000+ mls in total during first 2 sleep invocations and as result of it the counter peak value was evaluated due to finishing the sample period which is 1 second. It seems that thread overslept for more than 500mls which is quite unexpected value. Perhaps, extra GC activity caused it. I am not sure.
        Alex Rudyy made changes -
        Alex Rudyy made changes -
        Status In Progress [ 3 ] Ready To Review [ 10006 ]
        Hide
        Alex Rudyy added a comment -

        Robbie,

        Could you have a look at the patch attached?

        Show
        Alex Rudyy added a comment - Robbie, Could you have a look at the patch attached?
        Alex Rudyy made changes -
        Assignee Alex Rudyy [ alex.rufous ] Robbie Gemmell [ gemmellr ]
        Hide
        Robbie Gemmell added a comment -

        I have applied the patch, with a small update to ensure it doesnt result in negative values being used which will simply lead to a new failure mode. The patch looks like it should help, but it clearly wont be able to entirely fix the underlying issue leading to these sporadic failures; the tests highlights that they are pretty ugly and slightly indeterminate given their complete reliance on Thread.sleep() functionlity, so I have raised QPID-3811 to track future effort to make them more determinate (and faster!).

        Show
        Robbie Gemmell added a comment - I have applied the patch, with a small update to ensure it doesnt result in negative values being used which will simply lead to a new failure mode. The patch looks like it should help, but it clearly wont be able to entirely fix the underlying issue leading to these sporadic failures; the tests highlights that they are pretty ugly and slightly indeterminate given their complete reliance on Thread.sleep() functionlity, so I have raised QPID-3811 to track future effort to make them more determinate (and faster!).
        Robbie Gemmell made changes -
        Status Ready To Review [ 10006 ] Resolved [ 5 ]
        Resolution Fixed [ 1 ]
        Transition Time In Source Status Execution Times Last Executer Last Execution Date
        Open Open In Progress In Progress
        3d 3m 1 Alex Rudyy 03/Feb/12 15:39
        In Progress In Progress Reviewable Reviewable
        16m 54s 1 Alex Rudyy 03/Feb/12 15:56
        Reviewable Reviewable Resolved Resolved
        23h 34m 1 Robbie Gemmell 04/Feb/12 15:30

          People

          • Assignee:
            Robbie Gemmell
            Reporter:
            Alex Rudyy
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development