Menu

#48 Wrapper 3.1 Timer Problems

v3.1.0
closed-fixed
Misc (42)
5
2014-08-21
2004-05-07
Marc Lennox
No

We use wrapper to run our CruiseControl build loop
execution as a windows service. We recently upgraded
to 3.1 from 3.0.5 and have noticed a number of problems
that have forced us to revert to 3.0.5.

Initially, we did not make any configuration changes to
wrapper, we only simply upgraded to the latest release.
During our long overnight build and test, we started
getting errors such as:

Wrapper Process has not received any CPU time for
2787374857 seconds. Extending timeouts.

As well, the build process would simply hang
approximately 3 hours into it.

Next, I tried tweaking some of the new properties to use
the tick timer instead of the clock timer. With these
parameters, I started getting the following:

The system clock fell behind the timer by 69100ms.
FATAL | wrapper | 2004/05/07 03:26:42 | encountered
a fatal error in Wrapper
FATAL | wrapper | 2004/05/07 03:26:42 |
exceptionCode = EXCEPTION_ACCESS_VIOLATION
FATAL | wrapper | 2004/05/07 03:26:42 |
exceptionFlag =
EXCEPTION_NONCONTINUABLE_EXCEPTION
FATAL | wrapper | 2004/05/07 03:26:42 |
exceptionAddress = 0040E42A
FATAL | wrapper | 2004/05/07 03:26:42 | Write
access exception to 00000000
FATAL | wrapper | 2004/05/07 03:26:42 | Fatal error
in the Timer thread.

Again, this happened approximately 2 - 3 hours into the
process.

As background, the Wrapper is controlling the
CruiseControl java process, however CruiseControl is
configured to launch another JVM to perform the build
loop, which takes 5 hours.

It seems that the new version of wrapper has a problem
with "waiting" for the other JVM to exit for longer than a
certain time.

We have never seen these types of issues with 3.0.5

Thank you.

Discussion

<< < 1 2 (Page 2 of 2)
  • Leif Mortenson

    Leif Mortenson - 2004-07-21

    Logged In: YES
    user_id=228081

    Closing this off because 3.1.1 was released today.

     
  • Leif Mortenson

    Leif Mortenson - 2004-07-21
    • status: open-fixed --> closed-fixed
     
  • Marc Lennox

    Marc Lennox - 2004-07-21

    Logged In: YES
    user_id=505589

    Isn't this always the way... just last night, for the first time in
    over a month, we got another timer issue... I will update to
    3.1.1 and monitor the situation.

    INFO | wrapper | 2004/07/21 04:48:49 | The system clock
    fell behind the timer by 63300ms.
    INFO | jvm 1 | 2004/07/21 04:48:49 | The system clock
    fell behind the timer by 63300ms.

     
  • Leif Mortenson

    Leif Mortenson - 2004-07-21

    Logged In: YES
    user_id=228081

    Marc,
    The message you just saw was most likely caused by the
    system clock being set back by 63.3 seconds. The number is
    in ms so it appears large, but really isn't.

    Are you setting the following properties in your
    configuration file?
    wrapper.timer_fast_threshold
    wrapper.timer_slow_threshold

    Their defaults are quite large so I would not expect that
    you would have seen a message for a 1 minute adjustment.
    Never the less it is just a message and should have no
    affect on the Wrapper or JVM performance. I like to set
    the above properties to low values as it lets me know what
    is happening with system load and the clock.

    Cheers,
    Leif

     
  • Marc Lennox

    Marc Lennox - 2004-07-21

    Logged In: YES
    user_id=505589

    I've get them set to lower values... I'll remove and use the
    defaults. Unfortunately, when it happened it did cause our
    build process to freeze, requiring a restart.

     
  • Leif Mortenson

    Leif Mortenson - 2004-07-21

    Logged In: YES
    user_id=228081

    Marc,
    What about the build process froze? The message displayed
    was simply a notice that the Wrapepr noticed the time change
    and was behaving normally. I am pretty sure that the
    Wrapper was not the cause of the build freezing in this
    case.... but just after a release I am of course a bit
    nervous... Does the build process kick out any logs? I am
    wondering if the time change could have affected something
    else in your program?

    There should be no reason for you set the threshod values
    back to the defaults, I was just explaining what they meant.

    Cheers,
    Leif

     
  • Marc Lennox

    Marc Lennox - 2004-07-22

    Logged In: YES
    user_id=505589

    Leif, I think you are correct. I don't think the freeze is due to
    wrapper. Here is the log message that I'm seeing, but I think
    it's coming from CruiseControl... please confirm.

    INFO | jvm 1 | 2004/07/22 07:46:31 |
    java.lang.StackOverflowError

    Thanks.

     
  • Leif Mortenson

    Leif Mortenson - 2004-07-22
    • priority: 9 --> 5
     
  • Leif Mortenson

    Leif Mortenson - 2004-07-22

    Logged In: YES
    user_id=228081

    Marc,
    Just from that, it is hard to say exactle where it is coming
    from. But the Wrapper does not do any recursive calls so I
    don't think it is possible that it is a Wrapper problem. I
    have also never heard of or experienced such an erro coming
    from the Wrapper.

    Cheers,
    Leif

     
<< < 1 2 (Page 2 of 2)

Log in to post a comment.

MongoDB Logo MongoDB