Microsoft.XMLHTTP

[Vanessa]

I've been searching everywhere online to find an alternative method besides
using Microsoft.XMLHTTP (as it freezes the server up alot!!) but with no luck
at all.

I am using server side ASP, and some said to use Microsoft.ServerXMLHTTP
instead. However I have tried that as well and it still freezes up the whole
thing (i.e. the site just keeps loading forever).

I tried to do a "on error resume next" clause to catch the error but still
doesn't stop the page being freezing up..

I saw someone here said don't use XMLHTTP in ASP as it is not thread safe
(is that why it is freezing up??), and suggest to use
MSXML2.ServerXMLHTTP.3.0.

so do anyone know if MSXML2.ServerXMLHTTP.3.0 will help? i.e. not freezing
up the page? Please help!!!!!!

Vanessa

 

[Evertjan.]

=?Utf-8?B?VmFuZXNzYQ==?= wrote on 12 jul 2007 in
microsoft.public.inetserver.asp.general:

I've been searching everywhere online to find an alternative method
besides using Microsoft.XMLHTTP (as it freezes the server up alot!!)
but with no luck at all.

Does it really freeze the server, so no other users can access it,
and the server has to be restarted, or does it freeze the browser?

I am using server side ASP,

On your own machine via localhost:// or on the web?

and some said to use
Microsoft.ServerXMLHTTP instead. However I have tried that as well
and it still freezes up the whole thing (i.e. the site just keeps
loading forever).

Wouldn't that be because you made some error in your code?

Why not show your code, just an minimized example that does what you say.

I manage quite well with asp-vbscript:

Set objXMLHTTP = Server.CreateObject("Microsoft.XMLHTTP")

(i.e. the site just keeps loading forever).

Site's do not load, perhaps the server does, or the browser,
but in the case of Microsoft.XMLHTTP,
how do you know the supposed freezeup [of the server?] is caused by that?

I tried to do a "on error resume next" clause to catch the error but
still doesn't stop the page being freezing up..

So it is the page that is freezing up, not the server?
The browser, not the server?

"on error resume next" prohibits an error to be shown by the standard
error page of ASP, and to be later catched by your own code, it does not
catch errors that would not be signalled otherwise.

I saw someone here said don't use XMLHTTP in ASP as it is not thread
safe (is that why it is freezing up??), and suggest to use
MSXML2.ServerXMLHTTP.3.0.

Wrong approch, I think, first find the diagnosis, then the therapy.

Start with "What is freezing up?"

so do anyone know if MSXML2.ServerXMLHTTP.3.0 will help? i.e. not
freezing up the page? Please help!!!!!!

Again, show a simple code that does the harm you say.

 

[Anthony Jones]

I've been searching everywhere online to find an alternative method besides
using Microsoft.XMLHTTP (as it freezes the server up alot!!) but with no luck
at all.

I am using server side ASP, and some said to use Microsoft.ServerXMLHTTP
instead. However I have tried that as well and it still freezes up the whole
thing (i.e. the site just keeps loading forever).

I tried to do a "on error resume next" clause to catch the error but still
doesn't stop the page being freezing up..

I saw someone here said don't use XMLHTTP in ASP as it is not thread safe
(is that why it is freezing up??), and suggest to use
MSXML2.ServerXMLHTTP.3.0.

so do anyone know if MSXML2.ServerXMLHTTP.3.0 will help? i.e. not freezing
up the page? Please help!!!!!!

Vanessa

Yes you should be using ServerXMLHTTP. You should also be using the version
specific MSXML.ServerXMLHTTP.3.0.

Are you making a request back to your own server? If so it is prone to
deadlock. If you have ASP debugging on then you can't make a request to
another ASP page on your own server from ASP.

 

[Vanessa]

=?Utf-8?B?VmFuZXNzYQ==?= wrote on 12 jul 2007 in
microsoft.public.inetserver.asp.general:


Does it really freeze the server, so no other users can access it,
and the server has to be restarted, or does it freeze the browser?

I am not sure if it is freezing up the server or the browser, but when the
deadlock happened, I tried to access the site from different stations and all
browers are showing 'loading......' and it never responds. But the weird
thing is the other sections of the site which doesn't call any XMLHTTP
methods are still running and responding back. So is that freeze on the
browser or server?

At this case, I have to restart the IIS Admin Service and the site is back
to normal.

One thing I forgot to mention is -- it doesn't freeze all the times, most of
the time it is running fine and able to read/write data via XMLHTTP.

On your own machine via localhost:// or on the web?

On my company's website.

Wouldn't that be because you made some error in your code?

Why not show your code, just an minimized example that does what you say.

I manage quite well with asp-vbscript:

Set objXMLHTTP = Server.CreateObject("Microsoft.XMLHTTP")

Here is one section of my script:

PostURL = linkhome & "nav/GetCustomer.asp?CustomerID=" &CustomerID
Set xml = Server.CreateObject("Microsoft.XMLHTTP")
xml.Open "POST", PostURL, false,"",""
xml.Send
getcustomXML = xml.responseText
Set xml = Nothing

It seems like it got stuck at "xml.Send" line

(i.e. the site just keeps loading forever).

Site's do not load, perhaps the server does, or the browser,
but in the case of Microsoft.XMLHTTP,
how do you know the supposed freezeup [of the server?] is caused by that?

Actually I still can't figure out the exact cause of the freezeup so
please help!

 

[Vanessa]

Yes you should be using ServerXMLHTTP. You should also be using the version
specific MSXML.ServerXMLHTTP.3.0.

Are you making a request back to your own server? If so it is prone to
deadlock. If you have ASP debugging on then you can't make a request to
another ASP page on your own server from ASP.

Thanks Anthony for your response.

for example:

on CheckCustomer.asp:

'process some data

PostURL = linkhome & "/nav/GetCustomer.asp?CustomerID=" &CustomerID
Set xml = Server.CreateObject("Microsoft.XMLHTTP")
xml.Open "POST", PostURL, false,"",""
xml.Send
getcustomXML = xml.responseText
Set xml = Nothing

'process more data based on the getcustomXML

Yes, I am making a request back to my own server. Both the calling script
CheckCustomer.asp and the GetCustomer.asp are making read/write request to
our SQL server. So if that's the result that's cause the freezing, how can I
turn OFF the ASP debugging?

Thanks Much!

 

[Vanessa]

oh Anthony,

sorry I have one more question - what ASP debugging does? If I turn it off
will it affect anything?

 

[Evertjan.]

=?Utf-8?B?VmFuZXNzYQ==?= wrote on 12 jul 2007 in
microsoft.public.inetserver.asp.general:

[...]

On my company's website.



Here is one section of my script:

PostURL = linkhome & "nav/GetCustomer.asp?CustomerID=" &CustomerID
Set xml = Server.CreateObject("Microsoft.XMLHTTP")
xml.Open "POST", PostURL, false,"",""
xml.Send
getcustomXML = xml.responseText
Set xml = Nothing

It seems like it got stuck at "xml.Send" line

You seem to need TWO servers, one for the asp file with the
Server.CreateObject() in it [server1], and another [server2] where the
file the PostURL is pointing to, is located.

[If it is one and the same server, why not access the database directly]

Is this a correct assumption?

(i.e. the site just keeps loading forever).

Site's do not load, perhaps the server does, or the browser,
but in the case of Microsoft.XMLHTTP,
how do you know the supposed freezeup [of the server?] is caused by
that?

Actually I still can't figure out the exact cause of the freezeup
so please help!

I would start by using the above code in [server1] to fetch a simple page
in [server2] containing only some text, like "Hello world".

If that gets through, using

response.write getcustomXML

you could try to fetch something simple from your database on server1.

That way you either get lucky when all is working, or you know where you
get stuck, methinks.

 

[Anthony Jones]

Thanks Anthony for your response.

for example:

on CheckCustomer.asp:

'process some data

PostURL = linkhome & "/nav/GetCustomer.asp?CustomerID=" &CustomerID
Set xml = Server.CreateObject("Microsoft.XMLHTTP")
xml.Open "POST", PostURL, false,"",""
xml.Send
getcustomXML = xml.responseText
Set xml = Nothing

'process more data based on the getcustomXML

Yes, I am making a request back to my own server. Both the calling script
CheckCustomer.asp and the GetCustomer.asp are making read/write request to
our SQL server. So if that's the result that's cause the freezing, how can I
turn OFF the ASP debugging?

In IIS Manager open the properties dialog on the the web site or the folder
that represents the root of your application. On the home directory tab
click on the Congiuration... button. In the Application Configuration
dialog on the App Debugging tab clear the debugging flags.

You need consider in the real world how much activity your site will see.
If there is a possibility
that many simultaneous requests will be received for this page or ones like
it then you are still at risk to a dead lock.


Have you considered whether this sort of self request is really necessary?

For example, GetCustomer.asp generates XML. If the code is not already
doing so, use an XML DOM document to build the XML. Put all the code that
generates this XML into a function that returns an XML DOM Document. Have a
very small amount of code outside the function which calls it and then sends
the content of the DOM Document to the Response, eg:-

<%

Dim moXML
Dim mlCustID : mlCustID = CLng(Request.QueryString("CustomerID"))

Response.CharSet = "UTF-8"
Response.ContentType= "text/xml"

Set moXML = GetCustomer(mlCustID)
moXML.Save Response

Function GetCustomer(mlCustID)

Dim oXML : Set oXML = Server.CreateObject("MSXML.DOMDocument.3.0")
oXML.loadXML "<customer />"

oXML.documentElement.setAttribute("ID", mlCustID)

' other code where to build up the XML DOM.

Set GetCustomer = oXML

End Function

%>


Now create a new page called GetCustomerFuncs.asp cut the GetCustomer
function from the GetCustomer.ASP page and put it in this new page. Add an
#include to GetCustomer.asp to include GetCustomerFuncs.asp. This page will
continue to work as it did.

Now in CheckCustomer.asp you can also #include the GetCustmerFuncs.asp and
instead of all that XMLHTTP code you can simple call
GetCustomer(CustomerID).

 

[Anthony Jones]

oh Anthony,

sorry I have one more question - what ASP debugging does? If I turn it off
will it affect anything?

Yeah you won't be able to debug your ASP with a script debugger.

 

[Vanessa]

Anthony,

I have just checked my IIS setting and those debugging flags are un-checked
originally!!

Thanks for your information and I will see if I can make it work with your
approach.

However, there are some cases where the second script is actually an ASPX
page instead of ASP page, so will your approach work on this scenerio?

That is,
I will have customer.asp: to get the variable CustomerID.

Then thru XMLHTTP/ServerXMLHTTP pass it to checkCustomer.aspx (which is
located in some other folders at the same server). checkCustomer.aspx will
actually verify the customer id and return some customer information. The
reason why it has to be in ASPX is because it is connecting to some outside
sources which must be in the .net framework environment in order to work.

Then XMLHTTP will read the return from checkCustomer.aspx and pass the
control back to customer.asp and use the return variable to continue
processing the page.

Please advise as I am personally in a deadlock situation now... Many many
thanks!

Vanessa

 

[Vanessa]

Anthony,

A clarification on this -
"The reason why it has to be in ASPX is because it is connecting to some
outside
sources which must be in the .net framework environment in order to work."

Not really an outside source, it is still located at the same server, but it
will connect to another database within the same server through message queue
and Navision Application Server. Anyhow, so the second script will be in
asp.net page.

Please advise and thanks much!

 

[Anthony Jones]

Anthony,

A clarification on this -
"The reason why it has to be in ASPX is because it is connecting to some
outside
sources which must be in the .net framework environment in order to work."

Not really an outside source, it is still located at the same server, but it
will connect to another database within the same server through message queue
and Navision Application Server. Anyhow, so the second script will be in
asp.net page.

Please advise and thanks much!

I think we need to establish a few things to summarize where we are at this
point.

You are having a lock up occuring when making an XMLHTTP request to another
ASP page on the same server. You've switched to ServerXMLHTTP which is the
correct thing to do but that hasn't fixed it.

You've checked that ASP debugging is disabled and it is. Since you're just
testing this at the moment you're not likely to be running out of threads
and therefore its unlikely that you are really having a deadlock.

Now one thing I failed to establish at the start. The page that you are
calling, when called from browser or some other client that works right? It
doesn't just hang?

 

[Evertjan.]

Anthony Jones wrote on 14 jul 2007 in
microsoft.public.inetserver.asp.general:

I think we need to establish a few things to summarize where we are at
this point.

You are having a lock up occuring when making an XMLHTTP request to
another ASP page on the same server. You've switched to ServerXMLHTTP
which is the correct thing to do but that hasn't fixed it.

The Question remains if it is ever necessary to do a serverside XMLHTTP
request to another ASP page on the same(!!!) server.

I think not. All things that can be done,
can also done by straight code on the requesting page.

Correct me with an example, if I am wrong.

 

[Anthony Jones]

Anthony Jones wrote on 14 jul 2007 in
microsoft.public.inetserver.asp.general:


The Question remains if it is ever necessary to do a serverside XMLHTTP
request to another ASP page on the same(!!!) server.

I think not. All things that can be done,
can also done by straight code on the requesting page.

Correct me with an example, if I am wrong.

You're not wrong. I've already demonstrated how an ASP to ASP post can be
rearranged into a shared include and the reasons why it should.

The question that remains outstanding as I see it is why is this locking up?
Whilst I still think the self-post may be a candidate I'm no longer
convinced. In a test environment with debugging turned off there is no
reason for this to fail.

Since the final product is to actually be ASP to ASP.NET my original
suggestion isn't appropriate.

 

[Vanessa]

I think we need to establish a few things to summarize where we are at this
point.

You are having a lock up occuring when making an XMLHTTP request to another
ASP page on the same server. You've switched to ServerXMLHTTP which is the
correct thing to do but that hasn't fixed it.

Yes.
If I use XMLHTTP, the IE is just loading forever (i.e. hang).
If I use ServerXMLHTTP, it will give me time out error:
msxml3.dll error '80072ee2'
The operation timed out

But with your suggestion, I will change all scripts with "function & include
tag" approach instead. So I won't need to use XMLHTTP object for case where
calling script and responding script are both ASP pages (A.asp -> B.asp ->
A.asp).

You've checked that ASP debugging is disabled and it is. Since you're just
testing this at the moment you're not likely to be running out of threads
and therefore its unlikely that you are really having a deadlock.

Now I will run into the situation where A.asp calls C.aspx and then the
control needs to return to A.asp so that I can retain whatever states A.asp
has. Both A.asp and C.aspx are still on the same server.

I just had a testing script in above scenario running using ServerXMLHTTP
and it is running just fine now, but I am worried once this section goes live
I will run into the same hanging/deadlocking issue.

Now one thing I failed to establish at the start. The page that you are
calling, when called from browser or some other client that works right? It
doesn't just hang?

So do you mean if I call B.asp directly from browser will it hang? Good
question, I don't remember if I have tried running B.asp directly from
browser when A.asp hangs. I will keep it in mind if it happened again I will
check.

 

[Vanessa]

Anthony Jones wrote on 14 jul 2007 in
microsoft.public.inetserver.asp.general:


The Question remains if it is ever necessary to do a serverside XMLHTTP
request to another ASP page on the same(!!!) server.

I think not. All things that can be done,
can also done by straight code on the requesting page.

Correct me with an example, if I am wrong.

Yes, you are right. I will do it with the function & include tag approach
as Anthony suggested.

What if in this case: A.asp calls C.aspx then return control back to A.asp
without refresh? Any way to do it without using ServerXMLHTTP? or preventing
ServerXMLHTTP from hanging?

 

[Evertjan.]

=?Utf-8?B?VmFuZXNzYQ==?= wrote on 15 jul 2007 in
microsoft.public.inetserver.asp.general:

Yes, you are right. I will do it with the function & include tag
approach as Anthony suggested.

What if in this case: A.asp calls C.aspx then return control back to
A.asp without refresh? Any way to do it without using ServerXMLHTTP?
or preventing ServerXMLHTTP from hanging?

What do you exactly mean by "calls" in 'A.asp calls C.aspx'?
And what is 'return control back'?

In classic asp scripting "call" is invoking a subroutine only,
methinks.

Could you give a code example?

 

[Anthony Jones]

Yes.
If I use XMLHTTP, the IE is just loading forever (i.e. hang).
If I use ServerXMLHTTP, it will give me time out error:
msxml3.dll error '80072ee2'
The operation timed out

That could be due either to a deadlock or simply the called page is hung or
at least takes too long. ServerXMLHTTP has a default 30 second timeout
waiting for a response.

But with your suggestion, I will change all scripts with "function & include
tag" approach instead. So I won't need to use XMLHTTP object for case where
calling script and responding script are both ASP pages (A.asp -> B.asp ->
A.asp).

This won't work in ASP->ASP.NET situation which I thought was the thing you
really needed to do?

Now I will run into the situation where A.asp calls C.aspx and then the
control needs to return to A.asp so that I can retain whatever states A.asp
has. Both A.asp and C.aspx are still on the same server.

I just had a testing script in above scenario running using ServerXMLHTTP
and it is running just fine now, but I am worried once this section goes live
I will run into the same hanging/deadlocking issue.

In ASP->ASP.NET you will not run into the thread deadlock problem. (I've
tried three 'simple' explanations here, all failed to be simple so I'll just
leave it at that. )

So do you mean if I call B.asp directly from browser will it hang? Good
question, I don't remember if I have tried running B.asp directly from
browser when A.asp hangs. I will keep it in mind if it happened again I will
check.

Yes that's right I'm not fully convinced that you ever did have a deadlock
if you're just testing and you didn't have ASP debugging turned on.

 

[Vanessa]

=?Utf-8?B?VmFuZXNzYQ==?= wrote on 15 jul 2007 in
microsoft.public.inetserver.asp.general:


What do you exactly mean by "calls" in 'A.asp calls C.aspx'?
And what is 'return control back'?

In classic asp scripting "call" is invoking a subroutine only,
methinks.

Could you give a code example?

sorry for the confusing by using 'call'. Here is my code for
A.asp->C.aspx->A.asp now.

At Customer.asp file:

'....
'process list of data
'....


PostURL = homelink & "CustID.aspx?SearchFlag=PO"
set xmlhttp = CreateObject("MSXML2.ServerXMLHTTP.3.0")
on error resume next
xmlhttp.open "POST", PostURL, false
xmlhttp.send ""
status = xmlhttp.status
if err.number <> 0 or status <> 200 then
if status = 404 then
Response.Write "ERROR: Page does not exist (404).<BR><BR>"
elseif status >= 401 and status < 402 then
Response.Write "ERROR: Access denied (401).<BR><BR>"
elseif status >= 500 and status <= 600 then
Response.Write "ERROR: 500 Internal Server Error on remote
site.<BR><BR>"
else
Response.write "ERROR: Server is down or does not exist.<BR><BR>"
end if
else
'Response.Write "Server is up and URL is available.<BR><BR>"
getcustomXML = xmlhttp.responseText
end if
set xmlhttp = nothing


'use the value from getcustomXML to continue processing.
'....
'....

 

[Vanessa]

That could be due either to a deadlock or simply the called page is hung or
at least takes too long. ServerXMLHTTP has a default 30 second timeout
waiting for a response.

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?

This won't work in ASP->ASP.NET situation which I thought was the thing you
really needed to do?


In ASP->ASP.NET you will not run into the thread deadlock problem. (I've
tried three 'simple' explanations here, all failed to be simple so I'll just
leave it at that. )

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..

Yes that's right I'm not fully convinced that you ever did have a deadlock
if you're just testing and you didn't have ASP debugging turned on.

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.

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.

Thanks Much Anthony!!!!!