Last effort to solve threading issue

  • Thread starter Thread starter Brad Wood
  • Start date Start date
B

Brad Wood

Been working off and on with this for quite some time with no luck.
Last request before scrapping it.

Using a web service running framework 1.1 I'm creating threads and
making http calls within them.

The problem I'm having is that I get 2 exceptions (can't narrow down to
a particular line of my code - none of my exception handlers catch it)
when the http calls take a long time (which they do consistently):

<AbbreviatedStack>
[AppDomainUnloadedException]: Attempted to access an unloaded AppDomain.
at System.Threading.Thread.SetCompressedStackInternal()
at System.Threading.Thread.SetCompressedStack()
at System.Xml.XmlTextReader.CreateScanner()
at System.Xml.XmlTextReader.Init()
at System.Xml.XmlTextReader.Read()
at System.Xml.XmlReader.MoveToContent()
at System.Web.Configuration.XmlUtil.OpenXmlTextReader()
at System.Web.Configuration.HttpConfigurationRecord..ctor()
[ConfigurationException]: The XML file [machine.config] could not be
loaded. Attempted to access an unloaded AppDomain.
at System.Web.Configuration.HttpConfigurationSystem.CacheLookup()
at System.Web.Configuration.HttpConfigurationSystem.ComposeConfig()
at System.Web.HttpContext.GetCompleteConfigRecord()
at System.Web.HttpContext.GetCompleteConfig()
at System.Web.HttpContext.GetConfig()
at System.Web.HttpContext.GetMachineConfig()
at System.Web.HttpContext.GetAppLKGConfig()
</AbbreviatedStack>

I've tried all sorts of things like:
- Modified ASP.NET settings
- Reinstalled the framework and hotfix.
- Tried Thread.Sleep(0) in various places hoping to prevent some kind of
deadlock.

Is there a threading issue in general or any other clue someone might
have for me?

- desperate.
 
I don't know but...
this "The XML file [machine.config]" looks very suspicious.

it should be located here:
<WINDOWS>\Microsoft.NET\Framework\v1.1.4322\CONFIG\machine.config

If not.. maybe reinstall?

Also I will try to make an uneducated guess.
Maybe your threads have a longer lifespan that the method which initiate
them and the ASP.NET engine has unloaded the domain or something like that?
 
Hi Brad,

I put my two cents here:

executionTimeout in the web.config file? Make it huge or your appdomain will
be teared down with that exception.

Tried to disable virus scan software? There are some notes regarding a few
vscan programs that can give problems with .NET 1.1.

Laura
 
Lloyd said:
I don't know but...
this "The XML file [machine.config]" looks very suspicious.
it should be located here:
<WINDOWS>\Microsoft.NET\Framework\v1.1.4322\CONFIG\machine.config

Sorry, I was trying to trim the stack dump; it is located in the proper
location.
Also I will try to make an uneducated guess.
Maybe your threads have a longer lifespan that the method which initiate
them and the ASP.NET engine has unloaded the domain or something like that?

This is very logical, but doesn't seem possible since I'm calling join()
on every created thread before returning from the main WS method.

After all this time, I have new evidence:
Formerly, the error would consistently occur every other time I called
the WS. It didn't seem to matter how many http requests I made as long
as there were more than about 15. Because these trials took so long,
and because it didn't seem to matter exactly how many requests were
made, I would browse the Internet while they were running.

Today, I was unable to reproduce the error as long as I didn't do
anything else on my machine while they ran. The first time I ran a test
and browsed the Internet at the same time, it occurred again.

This really doesn't point me in any further troubleshooting direction
though...
 
Laura said:
executionTimeout in the web.config file? Make it huge or your appdomain will
be teared down with that exception.

Already tried that; tried it again just now to be sure (both app.config
and machine.config). No luck.
Tried to disable virus scan software? There are some notes regarding a few
vscan programs that can give problems with .NET 1.1.

Tried disabling and uninstalling. No luck. Thanks.
 
Brad,

are you sure you are not hiding any exceptions inside your code?
Is it only browsing that creates the problem or any a bit bigger app does
the same?
Could be a resource related problem if so.

Laura

Brad Wood said:
Lloyd said:
I don't know but...
this "The XML file [machine.config]" looks very suspicious.
it should be located here:
<WINDOWS>\Microsoft.NET\Framework\v1.1.4322\CONFIG\machine.config

Sorry, I was trying to trim the stack dump; it is located in the proper
location.
Also I will try to make an uneducated guess.
Maybe your threads have a longer lifespan that the method which initiate
them and the ASP.NET engine has unloaded the domain or something like
that?

This is very logical, but doesn't seem possible since I'm calling join()
on every created thread before returning from the main WS method.

After all this time, I have new evidence:
Formerly, the error would consistently occur every other time I called the
WS. It didn't seem to matter how many http requests I made as long as
there were more than about 15. Because these trials took so long, and
because it didn't seem to matter exactly how many requests were made, I
would browse the Internet while they were running.

Today, I was unable to reproduce the error as long as I didn't do anything
else on my machine while they ran. The first time I ran a test and
browsed the Internet at the same time, it occurred again.

This really doesn't point me in any further troubleshooting direction
though...
 
Laura said:
are you sure you are not hiding any exceptions inside your code?

Do you mean am I gobbling some exception that should more properly be
raised? If so, I don't think so.
When I wrap the entire WS method in an exception block, the error still
occurs. This would seem to indicate that the error is occurring within
the ASP.NET engine outside the scope of my code.
Is it only browsing that creates the problem or any a bit bigger app does
the same?
Could be a resource related problem if so.

My previous data now no longer applies. I would have thought that the
following would have narrowed it down:

- Error occurs every other WS call for *countless* attempts while
browsing Internet frequently during trials.
- Unable to reproduce error while not touching my machine for 10
straight trials.
- Error occurs very next attempt while browsing Internet on my machine.

but... I tried again to double check and did experience the error while
not touching my machine during the trial.
 
Brad,

I guess you have a resource leak somewhere, like missing dispose or too long
held references.
Check with performance monitor the handle and memory usage.

Laura
 
Laura said:
I guess you have a resource leak somewhere, like missing dispose or too long
held references.
Check with performance monitor the handle and memory usage.

If I see something in PerfMon, where do I look in code?

I've scoured the project (it's good sized, but not massive) for proper
usage of resources. Of course during the http calls HttpWebRequest
objects and stream readers for GetResponse are open for a long time, but
I can't change that. The calls are made to a very slow intranet resource.

Considering my errors (below), it seems that there is some timeout
somewhere that I'm unaware of:
- "machine.config could not be loaded" (in tandem with either "Attempted
to access an unloaded AppDomain" or "Resource lookup failed - infinite
recursion detected".
- When hosted remotely, I just get "http request timed out".

I think those errors are related only to the long execution time, not to
my code particularly.
- The http timeout can't be from my code because my HttpWebRequest
timeout is set to Timeout.Infinite (during testing anyway).
- The infinite recursion seems to be something going on inside the
ASP.NET engine trying to get to the machine.config. This error only
happens when the http requests take a long time.

So I'm thinking that in the OS there is some http timeout or in the
ASP.NET engine there is some timeout that causes an AppDomain that a
thread is running in to be unloaded (or some other such thing I have no
control over).

Thanks for the help. My next step is to use the http asynchronous calls
rather than creating my own threads. Hopefully there will be a
difference between the threads the framework creates and mine...
 
Back
Top