Evertjan. said:
NeedHelp wrote on 11 feb 2010 in microsoft.public.inetserver.asp.general:
[please do not quote signatures on usenet, that is "not done" on usenet.
Heh, I wrot that is thas last posting too.
Didn't you read that or don't you agree?]
Isn't there a netiquite rule about being an overly-insistent demanding
little sniveler? There ought to be, but regardless, I must admit it wasn't
100% clear to me what you were on about, the first time I read it. But then
again you're always on about something, which makes your nit-picks easy for
me to ignore... So when you encounter non-compliance, and feel compelled to
poll for the reason, you should add "didn't understand" and "don't really
care" to the list of options.
Why not?
I told you, the fetching of an external stream varies in time.
You cannot help the spead of that stream if that is due to the packet
stream of the Internet.
Yes but the default timeout is 90 seconds. Unless the request is highly
processor-intensive, for it to take anywhere near that long is usually
indicative of at least some problem. Even if absolutely nothing else, very
few users will wait that long for a web page to load, which constitutes a
problem in-and-of itself.
And it is always the first try that is slow, never the second, because if
the first is all right you do not try a second one.
The chance of twice slow being the square of a seldom event, so is far
more seldom.
Did you disprove my reasoning, or do you simply not read or like it?
If you set the timeout long enoug, the error will become lmore seldom, if
my surmize is valid.
Even so, you can catch errors and deal with it as you like serverside.
Where else can your ASP-code run?
Well, I run ASP code on my workstation pretty often, but that's not
important. Since the original question involved ServerXMLHTTP, I'm going to
go out on a limb and assume the ASP code to which the OP referred, is that
being called by ServerXMLHTTP. (This assumption adds infinite relevance,
and subtracts that statement-of-the-obvious quality that apparently drew
your sarcasm, don't you think?)
To the OP, you are aware that calls to ServerXMLHTTP must not send requests
to the same virtual server on which the calling script is executing,
correct? IOW, the script
http://www.myserver.com/xmlhttpcaller.asp must not
reference any other ASP script on
www.myserver.com when calling XMLHTTP.
Doing so can deadlock the script engine.
Even calling an XML source on a different virtual but same physical server
can cause issues, depending on app pools, isolation settings, threading
models of COM objects being used, etc. So if this is all running on the
same server box, I strongly suspect some sort of deadlock is intermittently
occurring. Timeout (like any other error) terminates the request, which
frees-up whatever resource is in contention, paving the way for the next
request to succeed as normal.
A telling test would be, next time the page that calls XMLHTTP takes longer
than a few seconds to complete, open the same page in another browser. If
that one hangs too, you've almost certainly got a deadlock on your hands.
Another diagnostic approach might be to set the timeout for the ASP page
that renders the XML to something very short (like 2x or 3x max amount of
time it should ever take to complete.) Then code the caller to check
status/eat errors/etc and retry a few times upon failure. (By default both
the caller and callee will timeout almost silmultaneously, but it doesn't
have to be that way.) Note that I'm not suggesting this for production
code, only for diagnostics.
-Mark
[If you don't want it quoted back, don't append it to your posts.]