I'm looking into a production issue related to a windows service and
System.Timers.Timer. The background is the windows service uses a
System.Timers.Timer to periodically poll a directory location on a
network for files and then copies these files to another location (on
the network) AND then updates a record in the database. The file
copying is performed before the database update because the file
system is not transactional.

The code C# .Net (2.0) has the required try/catch/finally to capture
any exception that might be generated during the Timer Elapsed event -
any errors that are generated are logged. I also know about the issue
relating to System.Timers.Timer swallowing unhandled exceptions. The
code also logic (locks) to prevent to Timer Elapsed event being
processed at the same time, the files are processed in a synchronous
manner.

The issue that is arising is intermittently files are being copied BUT
the database record is not being updated as expected AND there is no
error message in our logs. As I said this is an intermittent fault
that I can't reproduce on the development server even when I chuck a
large number of files (large file size as well) at it.

I want to know has anyone had any similar experiences.

Next step is to investigate the hardware & software configuration of
the production server.


Cheers

Ollie Riches

Re: Windows Service & System.Timers.Timer production issue... by mgsram

mgsram
Wed Apr 23 12:25:20 CDT 2008

On Apr 23, 12:28 pm, Ollie Riches <ollie.ric...@btinternet.com> wrote:
> I'm looking into a production issue related to a windows service and
> System.Timers.Timer. The background is the windows service uses a
> System.Timers.Timer to periodically poll a directory location on a
> network for files and then copies these files to another location (on
> the network) AND then updates a record in the database. The file
> copying is performed before the database update because the file
> system is not transactional.
>
> The code C# .Net (2.0) has the required try/catch/finally to capture
> any exception that might be generated during the Timer Elapsed event -
> any errors that are generated are logged. I also know about the issue
> relating to System.Timers.Timer swallowing unhandled exceptions. The
> code also logic (locks) to prevent to Timer Elapsed event being
> processed at the same time, the files are processed in a synchronous
> manner.
>
> The issue that is arising is intermittently files are being copied BUT
> the database record is not being updated as expected AND there is no
> error message in our logs. As I said this is an intermittent fault
> that I can't reproduce on the development server even when I chuck a
> large number of files (large file size as well) at it.
>
> I want to know has anyone had any similar experiences.
>
> Next step is to investigate the hardware & software configuration of
> the production server.
>
> Cheers
>
> Ollie Riches

1) Is it possible for you to paste the code block of the TimerElapsed
event handler? That would be helpful
2) Alternatively, run Perfmon and look at the count of CLR exceptions
for your process. This should tell you if there are unhandled
exceptions
3) Consider using FileSystemWatcher ( this is an alternative and not
really the solution to your problem)

-Sriram





Re: Windows Service & System.Timers.Timer production issue... by sloan

sloan
Wed Apr 23 13:10:37 CDT 2008

Check this post/thread:

http://groups.google.com/group/microsoft.public.dotnet.framework/browse_thread/thread/aa8a7a59b698f6b5/8b8c53ddf8298793?#8b8c53ddf8298793


I think its best to code up a TimerCallback...
have it do the work. ... and THEN code up another call to for the timer to
fire.

You'll avoid the space time continium ordeals when your code doesn't execute
before the next time a timer (the drag and drop kind) fires again.

I think that's the best way to approach it.


I would avoid
ElapsedEventHandler

and stick with this:
http://msdn2.microsoft.com/en-us/library/system.threading.timercallback.aspx



"Ollie Riches" <ollie.riches@btinternet.com> wrote in message
news:69b3ce1e-5996-4d07-9469-a54cd88c572d@24g2000hsh.googlegroups.com...
> I'm looking into a production issue related to a windows service and
> System.Timers.Timer. The background is the windows service uses a
> System.Timers.Timer to periodically poll a directory location on a
> network for files and then copies these files to another location (on
> the network) AND then updates a record in the database. The file
> copying is performed before the database update because the file
> system is not transactional.
>
> The code C# .Net (2.0) has the required try/catch/finally to capture
> any exception that might be generated during the Timer Elapsed event -
> any errors that are generated are logged. I also know about the issue
> relating to System.Timers.Timer swallowing unhandled exceptions. The
> code also logic (locks) to prevent to Timer Elapsed event being
> processed at the same time, the files are processed in a synchronous
> manner.
>
> The issue that is arising is intermittently files are being copied BUT
> the database record is not being updated as expected AND there is no
> error message in our logs. As I said this is an intermittent fault
> that I can't reproduce on the development server even when I chuck a
> large number of files (large file size as well) at it.
>
> I want to know has anyone had any similar experiences.
>
> Next step is to investigate the hardware & software configuration of
> the production server.
>
>
> Cheers
>
> Ollie Riches



Re: Windows Service & System.Timers.Timer production issue... by Ollie

Ollie
Wed Apr 23 14:47:37 CDT 2008

On 23 Apr, 18:25, mgsram <mgs...@gmail.com> wrote:
> On Apr 23, 12:28 pm, Ollie Riches <ollie.ric...@btinternet.com> wrote:
>
>
>
>
>
> > I'm looking into a production issue related to a windows service and
> > System.Timers.Timer. The background is the windows service uses a
> > System.Timers.Timer to periodically poll a directory location on a
> > network for files and then copies these files to another location (on
> > the network) AND then updates a record in the database. The file
> > copying is performed before the database update because the file
> > system is not transactional.
>
> > The code C# .Net (2.0) has the required try/catch/finally to capture
> > any exception that might be generated during the Timer Elapsed event -
> > any errors that are generated are logged. I also know about the issue
> > relating to System.Timers.Timer swallowing unhandled exceptions. The
> > code also logic (locks) to prevent to Timer Elapsed event being
> > processed at the same time, the files are processed in a synchronous
> > manner.
>
> > The issue that is arising is intermittently files are being copied BUT
> > the database record is not being updated as expected AND there is no
> > error message in our logs. As I said this is an intermittent fault
> > that I can't reproduce on the development server even when I chuck a
> > large number of files (large file size as well) at it.
>
> > I want to know has anyone had any similar experiences.
>
> > Next step is to investigate the hardware & software configuration of
> > the production server.
>
> > Cheers
>
> > Ollie Riches
>
> 1) Is it possible for you to paste the code block of the TimerElapsed
> event handler? That would be helpful
> 2) Alternatively, run Perfmon and look at the count of CLR exceptions
> for your process. This should tell you if there are unhandled
> exceptions
> 3) Consider using FileSystemWatcher ( this is an alternative and not
> really the solution to your problem)
>
> -Sriram- Hide quoted text -
>
> - Show quoted text -

1 - Sorry no I can't post the code,
2 - I don't have the opportunity to run perfmon on the production
server - security issues...
3 - FIleSystemWatcher is a possiblity but IMHO it has other issues
that cause problems.

Cheers

Ollie

Re: Windows Service & System.Timers.Timer production issue... by Ollie

Ollie
Wed Apr 23 14:56:02 CDT 2008

On 23 Apr, 19:10, "sloan" <sl...@ipass.net> wrote:
> Check this post/thread:
>
> http://groups.google.com/group/microsoft.public.dotnet.framework/brow...
>
> I think its best to code up a TimerCallback...
> have it do the work. ... and THEN code up another call to for the timer to
> fire.
>
> You'll avoid the space time continium ordeals when your code doesn't execute
> before the next time a timer (the drag and drop kind) fires again.
>
> I think that's the best way to approach it.
>
> I would avoid
> ElapsedEventHandler
>
> and stick with this:http://msdn2.microsoft.com/en-us/library/system.threading.timercallba...
>
> "Ollie Riches" <ollie.ric...@btinternet.com> wrote in message
>
> news:69b3ce1e-5996-4d07-9469-a54cd88c572d@24g2000hsh.googlegroups.com...
>
>
>
> > I'm looking into a production issue related to a windows service and
> > System.Timers.Timer. The background is the windows service uses a
> > System.Timers.Timer to periodically poll a directory location on a
> > network for files and then copies these files to another location (on
> > the network) AND then updates a record in the database. The file
> > copying is performed before the database update because the file
> > system is not transactional.
>
> > The code C# .Net (2.0) has the required try/catch/finally to capture
> > any exception that might be generated during the Timer Elapsed event -
> > any errors that are generated are logged. I also know about the issue
> > relating to System.Timers.Timer swallowing unhandled exceptions. The
> > code also logic (locks) to prevent to Timer Elapsed event being
> > processed at the same time, the files are processed in a synchronous
> > manner.
>
> > The issue that is arising is intermittently files are being copied BUT
> > the database record is not being updated as expected AND there is no
> > error message in our logs. As I said this is an intermittent fault
> > that I can't reproduce on the development server even when I chuck a
> > large number of files (large file size as well) at it.
>
> > I want to know has anyone had any similar experiences.
>
> > Next step is to investigate the hardware & software configuration of
> > the production server.
>
> > Cheers
>
> > Ollie Riches- Hide quoted text -
>
> - Show quoted text -

thanks but it is not a 'drag and drop' timer...

And the reason for not using Timers.Timer inside a windows service is
more a bad design than a failing in the implementation inside the
framework according to the MS KB article...

Cheers

Ollie



Re: Windows Service & System.Timers.Timer production issue... by sloan

sloan
Wed Apr 23 15:18:36 CDT 2008


I realize you do not have a drag and drop timer.

I pointed you to the other thread so you could find the KB discussing it.

..

The KB also states:
Additionally, use a System.Threading.Timer object instead of the
System.Timers.Timer object.


Of course its a design issue, or it wouldn't be listed as a bug on the MS KB
article with the word "BUG" in it.


But now you know how to code around it,...which is kinda the goal of your
post, isn't it? To figure out a way to get your code to work?

..






"Ollie Riches" <ollie.riches@btinternet.com> wrote in message
news:fa839bd8-cea9-4511-861c-3ec1e9abaa98@j22g2000hsf.googlegroups.com...
> On 23 Apr, 19:10, "sloan" <sl...@ipass.net> wrote:
>> Check this post/thread:
>>
>> http://groups.google.com/group/microsoft.public.dotnet.framework/brow...
>>
>> I think its best to code up a TimerCallback...
>> have it do the work. ... and THEN code up another call to for the timer
>> to
>> fire.
>>
>> You'll avoid the space time continium ordeals when your code doesn't
>> execute
>> before the next time a timer (the drag and drop kind) fires again.
>>
>> I think that's the best way to approach it.
>>
>> I would avoid
>> ElapsedEventHandler
>>
>> and stick with
>> this:http://msdn2.microsoft.com/en-us/library/system.threading.timercallba...
>>
>> "Ollie Riches" <ollie.ric...@btinternet.com> wrote in message
>>
>> news:69b3ce1e-5996-4d07-9469-a54cd88c572d@24g2000hsh.googlegroups.com...
>>
>>
>>
>> > I'm looking into a production issue related to a windows service and
>> > System.Timers.Timer. The background is the windows service uses a
>> > System.Timers.Timer to periodically poll a directory location on a
>> > network for files and then copies these files to another location (on
>> > the network) AND then updates a record in the database. The file
>> > copying is performed before the database update because the file
>> > system is not transactional.
>>
>> > The code C# .Net (2.0) has the required try/catch/finally to capture
>> > any exception that might be generated during the Timer Elapsed event -
>> > any errors that are generated are logged. I also know about the issue
>> > relating to System.Timers.Timer swallowing unhandled exceptions. The
>> > code also logic (locks) to prevent to Timer Elapsed event being
>> > processed at the same time, the files are processed in a synchronous
>> > manner.
>>
>> > The issue that is arising is intermittently files are being copied BUT
>> > the database record is not being updated as expected AND there is no
>> > error message in our logs. As I said this is an intermittent fault
>> > that I can't reproduce on the development server even when I chuck a
>> > large number of files (large file size as well) at it.
>>
>> > I want to know has anyone had any similar experiences.
>>
>> > Next step is to investigate the hardware & software configuration of
>> > the production server.
>>
>> > Cheers
>>
>> > Ollie Riches- Hide quoted text -
>>
>> - Show quoted text -
>
> thanks but it is not a 'drag and drop' timer...
>
> And the reason for not using Timers.Timer inside a windows service is
> more a bad design than a failing in the implementation inside the
> framework according to the MS KB article...
>
> Cheers
>
> Ollie
>
>



Re: Windows Service & System.Timers.Timer production issue... by Willy

Willy
Wed Apr 23 15:29:20 CDT 2008

Note that the KB clearly states that the BUG is in v1.0 and 1.1 only and
that there is a FIX.

Willy.


"sloan" <sloan@ipass.net> wrote in message
news:%23ea%23E7XpIHA.2068@TK2MSFTNGP05.phx.gbl...
>
> I realize you do not have a drag and drop timer.
>
> I pointed you to the other thread so you could find the KB discussing it.
>
> ..
>
> The KB also states:
> Additionally, use a System.Threading.Timer object instead of the
> System.Timers.Timer object.
>
>
> Of course its a design issue, or it wouldn't be listed as a bug on the MS
> KB article with the word "BUG" in it.
>
>
> But now you know how to code around it,...which is kinda the goal of your
> post, isn't it? To figure out a way to get your code to work?
>
> ..
>
>
>
>
>
>
> "Ollie Riches" <ollie.riches@btinternet.com> wrote in message
> news:fa839bd8-cea9-4511-861c-3ec1e9abaa98@j22g2000hsf.googlegroups.com...
>> On 23 Apr, 19:10, "sloan" <sl...@ipass.net> wrote:
>>> Check this post/thread:
>>>
>>> http://groups.google.com/group/microsoft.public.dotnet.framework/brow...
>>>
>>> I think its best to code up a TimerCallback...
>>> have it do the work. ... and THEN code up another call to for the timer
>>> to
>>> fire.
>>>
>>> You'll avoid the space time continium ordeals when your code doesn't
>>> execute
>>> before the next time a timer (the drag and drop kind) fires again.
>>>
>>> I think that's the best way to approach it.
>>>
>>> I would avoid
>>> ElapsedEventHandler
>>>
>>> and stick with
>>> this:http://msdn2.microsoft.com/en-us/library/system.threading.timercallba...
>>>
>>> "Ollie Riches" <ollie.ric...@btinternet.com> wrote in message
>>>
>>> news:69b3ce1e-5996-4d07-9469-a54cd88c572d@24g2000hsh.googlegroups.com...
>>>
>>>
>>>
>>> > I'm looking into a production issue related to a windows service and
>>> > System.Timers.Timer. The background is the windows service uses a
>>> > System.Timers.Timer to periodically poll a directory location on a
>>> > network for files and then copies these files to another location (on
>>> > the network) AND then updates a record in the database. The file
>>> > copying is performed before the database update because the file
>>> > system is not transactional.
>>>
>>> > The code C# .Net (2.0) has the required try/catch/finally to capture
>>> > any exception that might be generated during the Timer Elapsed event -
>>> > any errors that are generated are logged. I also know about the issue
>>> > relating to System.Timers.Timer swallowing unhandled exceptions. The
>>> > code also logic (locks) to prevent to Timer Elapsed event being
>>> > processed at the same time, the files are processed in a synchronous
>>> > manner.
>>>
>>> > The issue that is arising is intermittently files are being copied BUT
>>> > the database record is not being updated as expected AND there is no
>>> > error message in our logs. As I said this is an intermittent fault
>>> > that I can't reproduce on the development server even when I chuck a
>>> > large number of files (large file size as well) at it.
>>>
>>> > I want to know has anyone had any similar experiences.
>>>
>>> > Next step is to investigate the hardware & software configuration of
>>> > the production server.
>>>
>>> > Cheers
>>>
>>> > Ollie Riches- Hide quoted text -
>>>
>>> - Show quoted text -
>>
>> thanks but it is not a 'drag and drop' timer...
>>
>> And the reason for not using Timers.Timer inside a windows service is
>> more a bad design than a failing in the implementation inside the
>> framework according to the MS KB article...
>>
>> Cheers
>>
>> Ollie
>>
>>
>
>



Re: Windows Service & System.Timers.Timer production issue... by mgsram

mgsram
Wed Apr 23 15:41:49 CDT 2008

On Apr 23, 4:29 pm, "Willy Denoyette [MVP]"
<willy.denoye...@telenet.be> wrote:
> Note that the KB clearly states that the BUG is in v1.0 and 1.1 only and
> that there is a FIX.
>
> Willy.
>
> "sloan" <sl...@ipass.net> wrote in message
>
> news:%23ea%23E7XpIHA.2068@TK2MSFTNGP05.phx.gbl...
>
>
>
> > I realize you do not have a drag and drop timer.
>
> > I pointed you to the other thread so you could find the KB discussing it.
>
> > ..
>
> > The KB also states:
> > Additionally, use a System.Threading.Timer object instead of the
> > System.Timers.Timer object.
>
> > Of course its a design issue, or it wouldn't be listed as a bug on the MS
> > KB article with the word "BUG" in it.
>
> > But now you know how to code around it,...which is kinda the goal of your
> > post, isn't it? To figure out a way to get your code to work?
>
> > ..
>
> > "Ollie Riches" <ollie.ric...@btinternet.com> wrote in message
> >news:fa839bd8-cea9-4511-861c-3ec1e9abaa98@j22g2000hsf.googlegroups.com...
> >> On 23 Apr, 19:10, "sloan" <sl...@ipass.net> wrote:
> >>> Check this post/thread:
>
> >>>http://groups.google.com/group/microsoft.public.dotnet.framework/brow...
>
> >>> I think its best to code up a TimerCallback...
> >>> have it do the work. ... and THEN code up another call to for the timer
> >>> to
> >>> fire.
>
> >>> You'll avoid the space time continium ordeals when your code doesn't
> >>> execute
> >>> before the next time a timer (the drag and drop kind) fires again.
>
> >>> I think that's the best way to approach it.
>
> >>> I would avoid
> >>> ElapsedEventHandler
>
> >>> and stick with
> >>> this:http://msdn2.microsoft.com/en-us/library/system.threading.timercallba...
>
> >>> "Ollie Riches" <ollie.ric...@btinternet.com> wrote in message
>
> >>>news:69b3ce1e-5996-4d07-9469-a54cd88c572d@24g2000hsh.googlegroups.com...
>
> >>> > I'm looking into a production issue related to a windows service and
> >>> > System.Timers.Timer. The background is the windows service uses a
> >>> > System.Timers.Timer to periodically poll a directory location on a
> >>> > network for files and then copies these files to another location (on
> >>> > the network) AND then updates a record in the database. The file
> >>> > copying is performed before the database update because the file
> >>> > system is not transactional.
>
> >>> > The code C# .Net (2.0) has the required try/catch/finally to capture
> >>> > any exception that might be generated during the Timer Elapsed event -
> >>> > any errors that are generated are logged. I also know about the issue
> >>> > relating to System.Timers.Timer swallowing unhandled exceptions. The
> >>> > code also logic (locks) to prevent to Timer Elapsed event being
> >>> > processed at the same time, the files are processed in a synchronous
> >>> > manner.
>
> >>> > The issue that is arising is intermittently files are being copied BUT
> >>> > the database record is not being updated as expected AND there is no
> >>> > error message in our logs. As I said this is an intermittent fault
> >>> > that I can't reproduce on the development server even when I chuck a
> >>> > large number of files (large file size as well) at it.
>
> >>> > I want to know has anyone had any similar experiences.
>
> >>> > Next step is to investigate the hardware & software configuration of
> >>> > the production server.
>
> >>> > Cheers
>
> >>> > Ollie Riches- Hide quoted text -
>
> >>> - Show quoted text -
>
> >> thanks but it is not a 'drag and drop' timer...
>
> >> And the reason for not using Timers.Timer inside a windows service is
> >> more a bad design than a failing in the implementation inside the
> >> framework according to the MS KB article...
>
> >> Cheers
>
> >> Ollie

Its hard to say anything with the limited information. From what you
have narrated in your problem, all i can make out is that the
execution is broken causing event handlers to pile up. I did not mean
to ask for the actual code; a structure of the code block is also
sufficient.

Also whats the issue with using FileSystemWatcher, which IMO is the
optimal solution.

Re: Windows Service & System.Timers.Timer production issue... by Mr

Mr
Wed Apr 23 20:45:33 CDT 2008


"Ollie Riches" <ollie.riches@btinternet.com> wrote in message
news:69b3ce1e-5996-4d07-9469-a54cd88c572d@24g2000hsh.googlegroups.com...

> The code C# .Net (2.0) has the required try/catch/finally to capture
> any exception that might be generated during the Timer Elapsed event -
> any errors that are generated are logged. I also know about the issue
> relating to System.Timers.Timer swallowing unhandled exceptions. The
> code also logic (locks) to prevent to Timer Elapsed event being
> processed at the same time, the files are processed in a synchronous
> manner.

This is why I never use Timers.Timer in a Windows Service application. I
always spawn a thread and use the Thread.Timer instead, because of the
better exception handling within them.