Very odd beahvior of web application

Thread view:

Enable EMail Alerts

Start New Thread

Thread rating:

Mike Schilling - 14 Dec 2005 17:28 GMT

We have a C# application running under ASP.NET. It wasn't written using any
VS.NET magic; all of the call the System.Web are made explicitly. It uses
.NET 1.1; no other version of the framework is present on the machine.
There are two web.config files: the one at the top level specifies an
HttpModule, one in a subdirectory specifies an HttpHandler.

On some machines only, we see this odd behavior, and only after the app has
been running for some (variable) period of time: the HttpModule stops being
called. All requests for the vdir are still processed by ASP.NET, and URLs
including the subdirectory are still processed by its HttpHandler, but no
requests are processed by the HttpModule. Restarting IIS always fixes the
problem (temporarily).

First, has anyone seen anything like this. or has any ideas what might be
causing it?

Second, does anyone have ideas about how to debug it? We haven't found any
tracing to turn on, or any way to inquire of IIS/ASP.Net what it thinks the
state of the vdir or module is.

Reply to this Message

Alvin Bruney - ASP.NET MVP - 14 Dec 2005 19:24 GMT

Your first approach should be combing thru the application event logs to see
if something funny turns up. I suspect your module is failing.

I've never seen this before, but then again, i'm fresh here.

Signature

Regards,
Alvin Bruney [MVP ASP.NET]

[Shameless Author plug]
The Microsoft Office Web Components Black Book with .NET
Now Available @ www.lulu.com/owc
Forth-coming VSTO.NET - Wrox/Wiley 2006
-------------------------------------------------------

> We have a C# application running under ASP.NET. It wasn't written using any
> VS.NET magic; all of the call the System.Web are made explicitly. It uses
[quoted text clipped - 15 lines]
> tracing to turn on, or any way to inquire of IIS/ASP.Net what it thinks the
> state of the vdir or module is.

Reply to this Message

Mike Schilling - 14 Dec 2005 20:52 GMT

> Your first approach should be combing thru the application event logs to
> see
> if something funny turns up. I suspect your module is failing.

We haven't seen anything funny in the logs. What would "failing" mean here?
When a module throws exceptions, that will cause processing to be aborted
for the current message, but as far as I know it has no effect on other
threads. Or do you mean throwing an exception from Init() ?

Reply to this Message

Alvin Bruney - ASP.NET MVP - 15 Dec 2005 16:30 GMT

You'd need to assemble a test case. I suspect your module is dead. Here's
how to test that scenario. First clear your application logs. Add some code
in your module that writes an event to the event log every hour or so. Let
the application run. Examine the logs to see if the messages are continuous.
I suspect they stop after a while. Find out what the while is and if there
are any incidents that cause that action. That would be my first step.

Signature

> > Your first approach should be combing thru the application event logs to
> > see
[quoted text clipped - 4 lines]
> for the current message, but as far as I know it has no effect on other
> threads. Or do you mean throwing an exception from Init() ?

Reply to this Message

Mike Schilling - 15 Dec 2005 17:56 GMT

> You'd need to assemble a test case. I suspect your module is dead. Here's
> how to test that scenario. First clear your application logs. Add some
[quoted text clipped - 4 lines]
> I suspect they stop after a while. Find out what the while is and if there
> are any incidents that cause that action. That would be my first step.

Can you give me any hints about what sorts of things can kill modules? My
(possibly naive) view is that a module is an object created by the ASP.NET
runtime in response to configuration, that ASP.NET calls at defined times
during message processing. It doesn't have an associated thread that can
exit; it's called on the message-processing threads, possibly many at one
time. And as a managed object, it can't be manually deallocated. So what
does it mean that the module "dies", and how does that happen?

By the way, we've already put in tracing that shows that Dispose() isn't
being called on it.

Reply to this Message

Very odd beahvior of web application

Free Magazines