B
Brad Wood
I have a 1.1 web service that creates multiple threads and makes an http
call within each thread. When many threads are created, the service
fails every on other call with one of these 2 errors:
(1) Parser Error Message: </b>The XML file
c:\windows\microsoft.net\framework\v1.1.4322\Config\machine.config could
not be loaded. Attempted to access an unloaded AppDomain.
(2) Parser Error Message: </b>The XML file
c:\windows\microsoft.net\framework\v1.1.4322\Config\machine.config could
not be loaded. [Resource lookup failed - infinite recursion detected.
Resource name: Arg_AppDomainUnloadedException]
When I comment out my http call block, e.g.,
using(HttpWebResponse response = http.GetResponse() as HttpWebResponse)
{
...
}
The service does not fail (as I would expect).
However, when I leave the http call in and comment out three earlier
lines that access config constants, e.g.,
string s = ConfigurationSettings.AppSettings.Get(1);
The service does not fail either.
What's even crazier is that the service takes 10X longer with the calls
to ConfigurationSettings.AppSettings (I suppose because there is some
conflict between the threads). The NameValueCollection base class
underlying the AppSettings collection says that static members of this
type are thread-safe (which AppSettings is).
Why is the ConfigurationSettings class seeming to be so hosed up here?
call within each thread. When many threads are created, the service
fails every on other call with one of these 2 errors:
(1) Parser Error Message: </b>The XML file
c:\windows\microsoft.net\framework\v1.1.4322\Config\machine.config could
not be loaded. Attempted to access an unloaded AppDomain.
(2) Parser Error Message: </b>The XML file
c:\windows\microsoft.net\framework\v1.1.4322\Config\machine.config could
not be loaded. [Resource lookup failed - infinite recursion detected.
Resource name: Arg_AppDomainUnloadedException]
When I comment out my http call block, e.g.,
using(HttpWebResponse response = http.GetResponse() as HttpWebResponse)
{
...
}
The service does not fail (as I would expect).
However, when I leave the http call in and comment out three earlier
lines that access config constants, e.g.,
string s = ConfigurationSettings.AppSettings.Get(1);
The service does not fail either.
What's even crazier is that the service takes 10X longer with the calls
to ConfigurationSettings.AppSettings (I suppose because there is some
conflict between the threads). The NameValueCollection base class
underlying the AppSettings collection says that static members of this
type are thread-safe (which AppSettings is).
Why is the ConfigurationSettings class seeming to be so hosed up here?