System.Threading.Timers question

[Deiussum]

I'm running into an issue where I have a timer that appears to be timing
out immediately, when it shouldn't be timing out for about int.MaxValue
milliseconds. I have written a small app that isolates the problem and
was wondering if anyone had any ideas on what I am doing wrong, or if
there is some known bug, or I am exceeding some known maximum (which I
can't seen to find in documentation anywhere...)

Anyway, the following code used to appear to work fine. I didn't let it
run for the full 24 days, but the timer function didn't execute after
letting it run for a few hours. Now, the timer function gets executed
immediately. Here's the code:

using System;
class Test
{
static void Main(string[] args)
{
try
{
TimeSpan oSpan = TimeSpan.FromMilliseconds(int.MaxValue);

Console.WriteLine("Waiting for {0}", oSpan);

System.Threading.Timer oTimer = new System.Threading.Timer(
new System.Threading.TimerCallback(Thread),
null, oSpan, TimeSpan.FromMilliseconds(-1));

while(true);
}
catch (Exception e)
{
Console.WriteLine(e.Message);
}
finally
{
Console.WriteLine("Press enter to continue...");
Console.ReadLine();
}
}

static void Thread(object o)
{
Console.WriteLine("Thread...");
}
}

[Nicholas Paldino [.NET/C# MVP]]

Deiussum,

I've run this on .NET 2.0 (beta 1), and it doesn't give me any problems.
It basically starts waiting. I'm assuming after a day it will fire.

What version of .NET are you running? From what I understand of the
documentation, the timer should NOT fire immediately, and fire every day or
so.
--
- Nicholas Paldino [.NET/C# MVP]
- mv*@spam.guard.caspershouse.com

"Deiussum" <de******@lycanth.com> wrote in message
news:ux*************@TK2MSFTNGP12.phx.gbl...

I'm running into an issue where I have a timer that appears to be timing
out immediately, when it shouldn't be timing out for about int.MaxValue
milliseconds. I have written a small app that isolates the problem and
was wondering if anyone had any ideas on what I am doing wrong, or if
there is some known bug, or I am exceeding some known maximum (which I
can't seen to find in documentation anywhere...)

Anyway, the following code used to appear to work fine. I didn't let it
run for the full 24 days, but the timer function didn't execute after
letting it run for a few hours. Now, the timer function gets executed
immediately. Here's the code:

using System;
class Test
{
static void Main(string[] args)
{
try
{
TimeSpan oSpan = TimeSpan.FromMilliseconds(int.MaxValue);

Console.WriteLine("Waiting for {0}", oSpan);

System.Threading.Timer oTimer = new System.Threading.Timer(
new System.Threading.TimerCallback(Thread),
null, oSpan, TimeSpan.FromMilliseconds(-1));

while(true);
}
catch (Exception e)
{
Console.WriteLine(e.Message);
}
finally
{
Console.WriteLine("Press enter to continue...");
Console.ReadLine();
}
}

static void Thread(object o)
{
Console.WriteLine("Thread...");
}
}

[Deiussum]

Nicholas Paldino [.NET/C# MVP] wrote:

Deiussum,

I've run this on .NET 2.0 (beta 1), and it doesn't give me any problems.
It basically starts waiting. I'm assuming after a day it will fire.

What version of .NET are you running? From what I understand of the
documentation, the timer should NOT fire immediately, and fire every day or
so.

I'm running .Net 1.1. (The specific version reported in the control
panel 1.1.4322.573)

This is for enterprise software that we are developing, and won't likely
be updating to .Net 2.0 until it is well out of beta. Our QA team had
noted this problem awhile ago, but I was never able to reproduce it on
my own machine until recently. I'm guessing that possibly some of the
recent .Net fixes changed something?

The timespan in question is actually a bit over 24 days (24.20:31:23.647
to be exact.) I used -1 milliseconds for the repeat time, which MSDN
states to use if you do not want the periodic firing of the timer. I
just want it to fire once, but not until after the timeout time. :)

I also had tried using the overload that takes a uint representing the
number of milliseconds and got the same results.

[Deiussum]

It's gotten more interesting... In an attempt to find a lower maximum
to limit the timer to, I was trying to find out at what exact point the
problem occurs. The results are interesting...

I started to narrow it down to a timespan of:

TimeSpan oSpan = new TimeSpan(9, 17, 45, 0, 0);

I started trying to narrow down the seconds next, and found that after a
bit, the above timespan also showed the same problem, and I had to
change the timespan to:

TimeSpan oSpan = new TimeSpan(9, 17, 43, 0, 0);

Then a few minutes later, it had to be dropped down to:

TimeSpan oSpan = new TimeSpan(9, 17, 37, 0, 0);

Something definitely seems fishy about this...

[Deiussum]

I now have a theory on why this problem happens... I tried my test app
again this morning and the timer was expiring immediately at about
2005-04-07 04:21:0.000, but not at 04:20:0.000. (A timespan of rougly
7.20:04:00)

I then rebooted, tried it again, and now it all works.

My theory on what the bug is is this: Internally, the
System.Threading.Timers uses the number of milliseconds since the system
was last rebooted, and calculates what that value will be by the time it
should fire, using something like timeGetTime. According to MSDN, this
value wraps every 2^32 milliseconds, about 47.71 days. Since I seldom
reboot my machine, it has probably been running roughly 40 days, thus
when it tries to calculate the millisecond value since restart, it will
wrap, causing it to be LESS than the current millisecond value, and
therefore the timer will fire immediately.

--
Dan Jenkins <de******@lycanth.com>
Senior Software Engineer
Echelon Fargo

[Nick]

I've run into exactly this problem and am hoping to hear from Microsoft
whether it's a confirmed problem in .NET, perhaps with a fix in 2.0.

Basically, the two background System.Threading.Timers in our ASP.NET
application start freaking out when OS uptime reaches exactly 2^32
milliseconds (49.7 days). At that moment, timers that were set to fire
every 15 minutes start firing every 1 second.

This is on Windows Server 2003, .NET 1.1 SP1, IIS 6.0.

Thanks.
"Deiussum" wrote:

I now have a theory on why this problem happens... I tried my test app
again this morning and the timer was expiring immediately at about
2005-04-07 04:21:0.000, but not at 04:20:0.000. (A timespan of rougly
7.20:04:00)

I then rebooted, tried it again, and now it all works.

My theory on what the bug is is this: Internally, the
System.Threading.Timers uses the number of milliseconds since the system
was last rebooted, and calculates what that value will be by the time it
should fire, using something like timeGetTime. According to MSDN, this
value wraps every 2^32 milliseconds, about 47.71 days. Since I seldom
reboot my machine, it has probably been running roughly 40 days, thus
when it tries to calculate the millisecond value since restart, it will
wrap, causing it to be LESS than the current millisecond value, and
therefore the timer will fire immediately.

--
Dan Jenkins <de******@lycanth.com>
Senior Software Engineer
Echelon Fargo