D
Dave
Hi,
I have a very bizarre intermittent problem that occurs with some
ASP.NET 1.1 (C#) code I inherited. I'll try to state the problem
sucintly; if more detail is needed please ask! The code is in a
WebApplication. The web application is configured in IIS 6.0 to run
under Application Pools/Default App Pool.
The relevant code looks like this:
private bool ParseXML(string XmlResponseData, ref string
StatusMessage)
{
XmlNodeList List;
XmlNode AppServerNode;
XmlNode SubNode;
try
{
XmlDocument Document = new XmlDocument();
Document.LoadXml(XmlResponseData);
// lots of other code related to taking stuff out of Document
and putting into member variables omitted
}
catch
{
SetError("Failed to load XML response from server ");
return(false);
}
return(true);
}
Most of the time everything works fine. Once in a great while, the
code goes into the catch block. I can tell it goes into the catch
block because "SetError" is a function that ultimately logs the error
message. There is code right before this function that shows
XmlResponseData and logs it. As far as I can tell (and many others
who have stared at it) there is absolutely no difference between the
XML that works fine and the XML that causes the catch block to
execute. In fact, the evidence is stronger than that: we have the
ability to send the same message. Many of us are suspecting that the
lines "new XmlDocument()" or "Document.LoadXml(XmlResponseData)" are
failing (perhaps a memory problem?). Unfortunately, we can't
(currently) modify the code that is running to add more logging at key
places.
There is some more relevant information: Once the problem occurs, it
does not go away UNTIL someone does a "Recycle" on the DefaultAppPool
in IIS. I don't know much about IIS and Application Pools, so I have
no idea why this would fix the problem but it does (until the next
time of course). Another possibly related bit of information is that
the DefaultAppPool is set to auto recycle every 29 hours. Finally, we
occasionally have messages in the log of the form:
A process serving application pool 'DefaultAppPool' exceeded time
limits during shut down. The process id was '4244'
I realize that I probably need to give more details. The problem is
not well defined. I welcome all comments/suggestions/flames on how to
move forward or perform additional tests. Suggestions for more
appropriate newsgroups would also be most welcome. As you can see,
the problem seems to touch a few areas (ASP.NET, IIS, XML).
Sincerely,
Dave
I have a very bizarre intermittent problem that occurs with some
ASP.NET 1.1 (C#) code I inherited. I'll try to state the problem
sucintly; if more detail is needed please ask! The code is in a
WebApplication. The web application is configured in IIS 6.0 to run
under Application Pools/Default App Pool.
The relevant code looks like this:
private bool ParseXML(string XmlResponseData, ref string
StatusMessage)
{
XmlNodeList List;
XmlNode AppServerNode;
XmlNode SubNode;
try
{
XmlDocument Document = new XmlDocument();
Document.LoadXml(XmlResponseData);
// lots of other code related to taking stuff out of Document
and putting into member variables omitted
}
catch
{
SetError("Failed to load XML response from server ");
return(false);
}
return(true);
}
Most of the time everything works fine. Once in a great while, the
code goes into the catch block. I can tell it goes into the catch
block because "SetError" is a function that ultimately logs the error
message. There is code right before this function that shows
XmlResponseData and logs it. As far as I can tell (and many others
who have stared at it) there is absolutely no difference between the
XML that works fine and the XML that causes the catch block to
execute. In fact, the evidence is stronger than that: we have the
ability to send the same message. Many of us are suspecting that the
lines "new XmlDocument()" or "Document.LoadXml(XmlResponseData)" are
failing (perhaps a memory problem?). Unfortunately, we can't
(currently) modify the code that is running to add more logging at key
places.
There is some more relevant information: Once the problem occurs, it
does not go away UNTIL someone does a "Recycle" on the DefaultAppPool
in IIS. I don't know much about IIS and Application Pools, so I have
no idea why this would fix the problem but it does (until the next
time of course). Another possibly related bit of information is that
the DefaultAppPool is set to auto recycle every 29 hours. Finally, we
occasionally have messages in the log of the form:
A process serving application pool 'DefaultAppPool' exceeded time
limits during shut down. The process id was '4244'
I realize that I probably need to give more details. The problem is
not well defined. I welcome all comments/suggestions/flames on how to
move forward or perform additional tests. Suggestions for more
appropriate newsgroups would also be most welcome. As you can see,
the problem seems to touch a few areas (ASP.NET, IIS, XML).
Sincerely,
Dave