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.
Logged In: YES
user_id=228081
Closing this off because 3.1.1 was released today.
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.
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
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.
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
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.
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