Windows Service & System.Timers.Timer production issue...

  • Thread starter Thread starter Ollie Riches
  • Start date Start date
O

Ollie Riches

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
 
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
Click to expand...

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
 
Check this post/thread:

http://groups.google.com/group/micr...59b698f6b5/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
 
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 -
Click to expand...

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
 
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...










- Show quoted text -
Click to expand...

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
 
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?

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

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

Willy.
Click to expand...

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.
 
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.
Click to expand...

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.
 
Back
Top