views:

36

answers:

2

I have a web service written in C#. It behaves rather strange during pool recycling.

If I configure a pool with 5 worker processes which should recycle after say 100 requests (in production its actually 10000 but nevermind that). I get the proper response for the first 100 per process (i.e 500 requests), but after that some of the requests returns an improper result (i also get timeouts but that is okay as the process is recycling).

Since these improper results seems to happen AFTER the recycle, while the service is starting up it is kinda hard to just attach the debugger and see what happens (as the debugger is dettached when the recycle occurs).

So my question(s) is/are:
1. Do anybody know a good method for debugging this kind of thing

Edit: 2. Anbody who happens to have an idea on what might be wrong (the service has no state information between requests) - I found the error, by attaching the debugger and luckily seeing an exception (caught in a global exception handler - god i hate those): But the 1 question still stands. Is there an easier way than attaching the debugger and hope you make it in time to see the error.

A: 

You should make it clear what is the improper result. If it is not a .NET error, you should review your code and add some application level logging on your own code.

A debugger can only help when you have nothing else to resort to.

Lex Li
Well, i get an empty result, correctly formatted but no content - so most likely a null value somewhere. The code is part of a large library and nobody really cared about proper logging, and im not about to spread around random logging statements in thousands of code lines to figure out where my null value is being "created" (if such a thing can be said about a null value). At least not if I could attach the debugger and look for a nullreferenceexception (or similar).
Esben Bach
Personally I will capture exception dumps and analyze for the cause. But for you you may open a support case via http://support.microsoft.com when you need experts.
Lex Li
A: 

What I have ended up doing (for now), is to remove most of those "semi-global" try/catch/do-nothing handlers and then write a SoapExtension for handling "Unhandled Exceptions", and dump out all the information I can come near.

I got most the inspiration from Jeff Atwood's article on CodeProject: http://www.codeproject.com/kb/aspnet/ASPNETExceptionHandling.aspx

Its not really the same as attaching the debugger, but will have to do for now.

Esben Bach