Vanessa said:
Just curious, any way to set the default to a bit longer say a minute? Like
on scripting side or on the server property side?
The ServerXMLHTTP object has a setTimeouts method which takes 4 parameters:-
resolveTimeout, connectTimeout, sendTimeout, receiveTimeout
They are set in milliseconds.
Default values respectively are 0 (infinite), 60,000, 30,000, 30,000
(Note the documentation contradicts this but my experience shows that
ServerXMLHTTP actually gets its timeout defaults from the underlying WinHTTP
component).
So to set a minute receiveTimeout:-
oXMLHttp.setTimeouts 0, 60000, 30000, 60000
so ASP->ASP.NET won't run into the thread deadlock problem? Can you explain
why, sorry if you did it before as I am a bit confused.
pls... pls..
Threads used to process ASP scripts are managed by the ASP.DLL and by
default it will allow 25 threads per processor to run at the same time.
Threads used to process ASP.NET pages are managed by the ASP.NET run-time
and it uses a similar pool of threads.
Key point is that these are different pools of threads.
For purposes of an example lets assume that both pools can only have one
thread.
When an ASP page makes requests an other ASP page from the same application
the first ASP page blocks waiting for the second to complete. Whilst the
thread executing the page has nothing to do right now it can not be given to
another ASP request since it hasn't yet finished with the current one.
Now the request for the second ASP page will end up in the queue waiting to
be processed. It has to wait until a thread comes free in the pool. But
thats never going to happen because the one thread in the pools is currently
waiting for the queued request to finish. Deadlock
However when the second page is an ASPX page that page can be executed
because there is a thread available in ASP.NET pool of threads. Even if the
all threads in ASP.NET are currently busy eventually a thread will become
available and things will continue.
oh oh maybe I didn't make it clear before:
for case A.asp->B.asp->A.asp with XMLHTTP:
They are LIVE sections so users do use them alot, which creates a 'hanging'
situation once in a while. But I will change them to include tag approach so
it won't use XMLHTTP anymore thus it should be solved.
ok
for case A.asp->C.aspx->A.asp with ServerXMLHTTP:
It is what I am currently working on as testing for my new project, the
sections have gone live yet. Right now it is running fine, so just hope
deadlock situation won't happen in there when live.
Again, in both cases
- all scripts are located at the same server, and
- ASP Debugging is OFF.
Yes I think you will be ok with this. It's less than ideal a more logical
architecute might be to build a component in .NET that can be shared by both
ASP code (through a COM interop interface) and ASP.NET. However that is
probably far to much of a change than is warranted.
