|
web
newsgroups
|
|||||||||||||||||||||||
|
|||||||||||||||||||||||
VB.Net Timer IssueI have recently discovered that the system.Timers.Timer from.Net
Framework v1.1 is not reliable when used on Windows 2003 server. When incorporated into a Windows Service, the timer_elapsed event will stop executing after 30 to 40 days. After learning this, I found the same issue had been documented in the the System.Threading.Timer class as well. This limits my options for having a timer based windows service using the .net framework. I can convert the project to .Net Framework 2.0, but I am unsure whether or not this will resolve the issue. Any ideas would be helpful. Thank you. Why do I think the actual problem occurs at 49.7 days. This is a known
issue with 32 bit windows (2^31-1 milliseconds is about 49.7 days). It's not that the timer service stops, it's that the internal timers wrap back to zero and the trigger doesn't occur anymore. The work around is to track what day or month it is (numeric day of month or month of year is sufficient) Here's an example workaround. Module Module1 Public ReadOnly Interval As New System.TimeSpan(1, 0, 0) Public t As New System.Timers.Timer(Interval.Milliseconds) Public MonthNumber As Integer = Today.Month Sub Main() AddHandler t.Elapsed, AddressOf t_Elapsed t.Start() End Sub Private Sub t_Elapsed(ByVal sender As Object, ByVal e As System.Timers.ElapsedEventArgs) If MonthNumber <> Today.Month Then RemoveHandler t.Elapsed, AddressOf t_Elapsed MonthNumber = Today.Month t = New System.Timers.Timer(Interval.Milliseconds) AddHandler t.Elapsed, AddressOf t_Elapsed t.Start() End If ' Proceess timer event End Sub End Module Mike Ober. Show quoteHide quote "igor" <jones_i***@yahoo.com> wrote in message news:1167168930.265904.288150@a3g2000cwd.googlegroups.com... >I have recently discovered that the system.Timers.Timer from.Net > Framework v1.1 is not reliable when used on Windows 2003 server. When > incorporated into a Windows Service, the timer_elapsed event will stop > executing after 30 to 40 days. After learning this, I found the same > issue had been documented in the the System.Threading.Timer class as > well. This limits my options for having a timer based windows service > using the .net framework. > > I can convert the project to .Net Framework 2.0, but I am unsure > whether or not this will resolve the issue. > > Any ideas would be helpful. > > Thank you. > Michael,
Thank you for your help. I have a couple of questions. Why is it that resetting the timer variable to a new instance every month fixes the issue? If the System.Timers.Timer class elapsed events fire when the internal timer reaches a specific future time value, than wouldn't any elapsed event set to fire after the 49.7 day point fail? As I understand it, the internal timer you mention is the timer which starts when the server is rebooted and increments until the 49.7 day point is reached. Thanks again Michael D. Ober wrote: Show quoteHide quote > Why do I think the actual problem occurs at 49.7 days. This is a known > issue with 32 bit windows (2^31-1 milliseconds is about 49.7 days). It's > not that the timer service stops, it's that the internal timers wrap back to > zero and the trigger doesn't occur anymore. The work around is to track > what day or month it is (numeric day of month or month of year is > sufficient) Here's an example workaround. > > Module Module1 > Public ReadOnly Interval As New System.TimeSpan(1, 0, 0) > Public t As New System.Timers.Timer(Interval.Milliseconds) > Public MonthNumber As Integer = Today.Month > > Sub Main() > AddHandler t.Elapsed, AddressOf t_Elapsed > t.Start() > End Sub > > Private Sub t_Elapsed(ByVal sender As Object, ByVal e As > System.Timers.ElapsedEventArgs) > If MonthNumber <> Today.Month Then > RemoveHandler t.Elapsed, AddressOf t_Elapsed > MonthNumber = Today.Month > t = New System.Timers.Timer(Interval.Milliseconds) > AddHandler t.Elapsed, AddressOf t_Elapsed > t.Start() > End If > > ' Proceess timer event > End Sub > > End Module > > > Mike Ober. > > "igor" <jones_i***@yahoo.com> wrote in message > news:1167168930.265904.288150@a3g2000cwd.googlegroups.com... > >I have recently discovered that the system.Timers.Timer from.Net > > Framework v1.1 is not reliable when used on Windows 2003 server. When > > incorporated into a Windows Service, the timer_elapsed event will stop > > executing after 30 to 40 days. After learning this, I found the same > > issue had been documented in the the System.Threading.Timer class as > > well. This limits my options for having a timer based windows service > > using the .net framework. > > > > I can convert the project to .Net Framework 2.0, but I am unsure > > whether or not this will resolve the issue. > > > > Any ideas would be helpful. > > > > Thank you. > > I'm guessing here on the solution as it sounds like the 32 bit millisecond
rollover. As for why the creation of a new timer - this should initialize the timer to "0" and then it should be able to run for 49.7 days. When windows hits 49.7 days (2^31-1) milliseconds, it simply rolls over to 0. Windows 95 would actually become unstable at this point (if it hadn't already done so from usage). As for your question, I don't have an answer since for longer time periods I use the task manager to start an application at a specific time and not application code. Mike. Show quoteHide quote "igor" <jones_i***@yahoo.com> wrote in message news:1167264409.774432.189410@h40g2000cwb.googlegroups.com... > Michael, > Thank you for your help. I have a couple of questions. Why is it > that resetting the timer variable to a new instance every month fixes > the issue? If the System.Timers.Timer class elapsed events fire when > the internal timer reaches a specific future time value, than wouldn't > any elapsed event set to fire after the 49.7 day point fail? > > As I understand it, the internal timer you mention is the timer which > starts when the server is rebooted and increments until the 49.7 day > point is reached. > > Thanks again > > > > Michael D. Ober wrote: >> Why do I think the actual problem occurs at 49.7 days. This is a known >> issue with 32 bit windows (2^31-1 milliseconds is about 49.7 days). It's >> not that the timer service stops, it's that the internal timers wrap back >> to >> zero and the trigger doesn't occur anymore. The work around is to track >> what day or month it is (numeric day of month or month of year is >> sufficient) Here's an example workaround. >> >> Module Module1 >> Public ReadOnly Interval As New System.TimeSpan(1, 0, 0) >> Public t As New System.Timers.Timer(Interval.Milliseconds) >> Public MonthNumber As Integer = Today.Month >> >> Sub Main() >> AddHandler t.Elapsed, AddressOf t_Elapsed >> t.Start() >> End Sub >> >> Private Sub t_Elapsed(ByVal sender As Object, ByVal e As >> System.Timers.ElapsedEventArgs) >> If MonthNumber <> Today.Month Then >> RemoveHandler t.Elapsed, AddressOf t_Elapsed >> MonthNumber = Today.Month >> t = New System.Timers.Timer(Interval.Milliseconds) >> AddHandler t.Elapsed, AddressOf t_Elapsed >> t.Start() >> End If >> >> ' Proceess timer event >> End Sub >> >> End Module >> >> >> Mike Ober. >> >> "igor" <jones_i***@yahoo.com> wrote in message >> news:1167168930.265904.288150@a3g2000cwd.googlegroups.com... >> >I have recently discovered that the system.Timers.Timer from.Net >> > Framework v1.1 is not reliable when used on Windows 2003 server. When >> > incorporated into a Windows Service, the timer_elapsed event will stop >> > executing after 30 to 40 days. After learning this, I found the same >> > issue had been documented in the the System.Threading.Timer class as >> > well. This limits my options for having a timer based windows service >> > using the .net framework. >> > >> > I can convert the project to .Net Framework 2.0, but I am unsure >> > whether or not this will resolve the issue. >> > >> > Any ideas would be helpful. >> > >> > Thank you. >> > > "Michael D. Ober" <ober***@.alum.mit.edu.nospam> wrote in I recall seeing a KB article about this... do you happen to have any links news:#Ywm#icKHHA.3872@TK2MSFTNGP06.phx.gbl: > Why do I think the actual problem occurs at 49.7 days. This is a > known issue with 32 bit windows (2^31-1 milliseconds is about 49.7 > days). It's not that the timer service stops, it's that the internal > timers wrap back to zero and the trigger doesn't occur anymore. The > work around is to track what day or month it is (numeric day of month > or month of year is sufficient) Here's an example workaround. to any MS documentation? I did find an article Joel on Software linked - Southern California's ATC servers crashed after 49.7 days. But I thought MS fixed this in a service pack? No links to documentation. Just my memory that this was a problem with
Windows 95 and early versions of NT prior to one of the NT4 service packs. As far as I know, the server crash issue was fixed in Windows 98 and 2000. However, the underlying problem itself - 32 bit timer counters rolling over after 49.7 days will not be resolved until the transition to 64 bit computing is complete. Then the rollover time will be measured in centuries. Mike. Show quoteHide quote "Spam Catcher" <spamhoneypot@rogers.com> wrote in message news:Xns98A78E9B564EEusenethoneypotrogers@127.0.0.1... > "Michael D. Ober" <ober***@.alum.mit.edu.nospam> wrote in > news:#Ywm#icKHHA.3872@TK2MSFTNGP06.phx.gbl: > >> Why do I think the actual problem occurs at 49.7 days. This is a >> known issue with 32 bit windows (2^31-1 milliseconds is about 49.7 >> days). It's not that the timer service stops, it's that the internal >> timers wrap back to zero and the trigger doesn't occur anymore. The >> work around is to track what day or month it is (numeric day of month >> or month of year is sufficient) Here's an example workaround. > > I recall seeing a KB article about this... do you happen to have any links > to any MS documentation? > > > I did find an article Joel on Software linked - Southern California's ATC > servers crashed after 49.7 days. > > But I thought MS fixed this in a service pack? "Michael D. Ober" <ober***@.alum.mit.edu.nospam> wrote in Here's the SP: http://support.microsoft.com/kb/843561/en-usnews:e6JG#znLHHA.3560@TK2MSFTNGP02.phx.gbl: > No links to documentation. Just my memory that this was a problem > with Windows 95 and early versions of NT prior to one of the NT4 > service packs. As far as I know, the server crash issue was fixed in > Windows 98 and 2000. However, the underlying problem itself - 32 bit > timer counters rolling over after 49.7 days will not be resolved until > the transition to 64 bit computing is complete. Then the rollover > time will be measured in centuries. You would think MS would have caught this during .NET 1.1 development since
the OS teams had already addressed and fixed problems with the same underlying tickcount rollover. Mike. Show quoteHide quote "Spam Catcher" <spamhoneypot@rogers.com> wrote in message news:Xns98AC9A2C96DB5usenethoneypotrogers@127.0.0.1... > "Michael D. Ober" <ober***@.alum.mit.edu.nospam> wrote in > news:e6JG#znLHHA.3560@TK2MSFTNGP02.phx.gbl: > >> No links to documentation. Just my memory that this was a problem >> with Windows 95 and early versions of NT prior to one of the NT4 >> service packs. As far as I know, the server crash issue was fixed in >> Windows 98 and 2000. However, the underlying problem itself - 32 bit >> timer counters rolling over after 49.7 days will not be resolved until >> the transition to 64 bit computing is complete. Then the rollover >> time will be measured in centuries. > > Here's the SP: http://support.microsoft.com/kb/843561/en-us > "Michael D. Ober" <obermd.@.alum.mit.edu.no.spam> wrote in I noticed in Microsoft's KB that .NET CF 2.0 was still affected until a news:15Emh.6803$w91.6353@newsread1.news.pas.earthlink.net: > You would think MS would have caught this during .NET 1.1 development > since the OS teams had already addressed and fixed problems with the > same underlying tickcount rollover. recent SP ;-) "igor" <jones_i***@yahoo.com> wrote in news:1167168930.265904.288150 @a3g2000cwd.googlegroups.com:> I have recently discovered that the system.Timers.Timer from.Net Seems like there is a hotfix:> Framework v1.1 is not reliable when used on Windows 2003 server. When > incorporated into a Windows Service, the timer_elapsed event will stop > executing after 30 to 40 days. After learning this, I found the same > issue had been documented in the the System.Threading.Timer class as > well. This limits my options for having a timer based windows service > using the .net framework. > > I can convert the project to .Net Framework 2.0, but I am unsure > whether or not this will resolve the issue. ..NET 1.1 http://support.microsoft.com/kb/843561/en-us igor wrote:
> I have recently discovered that the system.Timers.Timer from.Net Only use the Timer to sidestep the Service's OnStart routine.> Framework v1.1 is not reliable when used on Windows 2003 server. When > incorporated into a Windows Service, the timer_elapsed event will stop > executing after 30 to 40 days. After learning this, I found the same > issue had been documented in the the System.Threading.Timer class as > well. This limits my options for having a timer based windows service > using the .net framework. Within your "main processing" loop, use Threading.Sleep() instead, as in Imports System.Threading Private _bStopRequested as Boolean Private _bStopped as Boolean Sub OnStart() tmrBoot.Start() End Sub Sub OnStop() _bStopRequested = True Do While Not _bStopped Thread.Sleep(500) Loop End Sub Sub tmrBoot_Timer() tmrBoot.Stop() Me.Run() End Sub Sub Run() _Stopped = False Do While Not bStopRequested ' Do the real work here Thread.Sleep(1000) Loop _Stopped = True End Sub HTH, Phill W. 
Other interesting topics
Problem With DoEvents
ADO.NET Problem write or wrong Launching Web site for help Cross: Access speed Small question? vbc : error BC30420: 'Sub Main' was not found in 'Product'. Is it necessary to close a local OleDbDataReader before exit function? VB Smart Devivce Programming Changing user interface DataGridView Questions |
|||||||||||||||||||||||
