Microsoft.XMLHTTP

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

Re: Microsoft.XMLHTTP

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

--
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)

Re: Microsoft.XMLHTTP

"Vanessa" wrote in message
news:0B65975E-3B9A-4E32-846E-555432A72C47@microsoft.com...
> 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.


--
Anthony Jones - MVP ASP/ASP.NET

Re: Microsoft.XMLHTTP

"Evertjan." wrote:

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

>
> > I am using server side ASP,
>
> On your own machine via localhost:// or on the web?


On my company's website.

>
> > 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")


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!


> > 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.
>
> --
> Evertjan.
> The Netherlands.
> (Please change the x'es to dots in my emailaddress)
>

Re: Microsoft.XMLHTTP

"Anthony Jones" wrote:

>
> "Vanessa" wrote in message
> news:0B65975E-3B9A-4E32-846E-555432A72C47@microsoft.com...
> > 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.
>
>
> --
> Anthony Jones - MVP ASP/ASP.NET
>
>

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

Re: Microsoft.XMLHTTP

oh Anthony,

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

"Anthony Jones" wrote:

>
> "Vanessa" wrote in message
> news:0B65975E-3B9A-4E32-846E-555432A72C47@microsoft.com...
> > 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.
>
>
> --
> Anthony Jones - MVP ASP/ASP.NET
>
>
>

Re: Microsoft.XMLHTTP

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

[...]
>> > I am using server side ASP,
>>
>> On your own machine via localhost:// or on the web?
>
>
> On my company's website.
>
>>
>> > 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")
>
>
> 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.

--
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)

Re: Microsoft.XMLHTTP

"Vanessa" wrote in message
news:0E261DF8-1BD0-441B-9938-3C89AAB06DFA@microsoft.com...
>
>
> "Anthony Jones" wrote:
>
> >
> > "Vanessa" wrote in message
> > news:0B65975E-3B9A-4E32-846E-555432A72C47@microsoft.com...
> > > 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.
> >
> >
> > --
> > Anthony Jones - MVP ASP/ASP.NET
> >
> >
>
> 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 ""

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 - MVP ASP/ASP.NET

Re: Microsoft.XMLHTTP

"Vanessa" wrote in message
news:D8EC564A-2B75-4186-B9E5-922BA31E662A@microsoft.com...
> 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.

--
Anthony Jones - MVP ASP/ASP.NET

Re: Microsoft.XMLHTTP

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


"Anthony Jones" wrote:

>
> "Vanessa" wrote in message
> news:0E261DF8-1BD0-441B-9938-3C89AAB06DFA@microsoft.com...
> >
> >
> > "Anthony Jones" wrote:
> >
> > >
> > > "Vanessa" wrote in message
> > > news:0B65975E-3B9A-4E32-846E-555432A72C47@microsoft.com...
> > > > 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.
> > >
> > >
> > > --
> > > Anthony Jones - MVP ASP/ASP.NET
> > >
> > >
> >
> > 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 ""
>
> 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 - MVP ASP/ASP.NET
>
>
>

Re: Microsoft.XMLHTTP

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!

Re: Microsoft.XMLHTTP

"Vanessa" wrote in message
news:A3A39D92-857B-4F3C-A993-7F1D48076B65@microsoft.com...
> 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?

--
Anthony Jones - MVP ASP/ASP.NET

Re: Microsoft.XMLHTTP

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.

--
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)

Re: Microsoft.XMLHTTP

"Evertjan." wrote in message
news:Xns996D9F920151eejj99@194.109.133.242...
> 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.

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.


--
Anthony Jones - MVP ASP/ASP.NET

Re: Microsoft.XMLHTTP

"Anthony Jones" wrote:
>
>
> "Vanessa" wrote in message
> news:A3A39D92-857B-4F3C-A993-7F1D48076B65@microsoft.com...
> > 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.
>

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.

> --
> Anthony Jones - MVP ASP/ASP.NET
>
>
>

Re: Microsoft.XMLHTTP

"Evertjan." wrote:

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

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.
> The Netherlands.
> (Please change the x'es to dots in my emailaddress)
>

Re: Microsoft.XMLHTTP

=?Utf-8?B?VmFuZXNzYQ==?= wrote on 15 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?
>

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?

--
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)

Re: Microsoft.XMLHTTP

"Vanessa" wrote in message
news:465DE78A-6BE7-4703-876D-78785C92B2CA@microsoft.com...
>
> "Anthony Jones" wrote:
> >
> >
> > "Vanessa" wrote in message
> > news:A3A39D92-857B-4F3C-A993-7F1D48076B65@microsoft.com...
> > > 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.
> >
>
> 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?

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

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

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

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.


--
Anthony Jones - MVP ASP/ASP.NET

Re: Microsoft.XMLHTTP

"Evertjan." wrote:

> =?Utf-8?B?VmFuZXNzYQ==?= wrote on 15 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?
> >
>
> 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).

"
elseif status >= 401 and status < 402 then
Response.Write "ERROR: Access denied (401).

"
elseif status >= 500 and status <= 600 then
Response.Write "ERROR: 500 Internal Server Error on remote
site.

"
else
Response.write "ERROR: Server is down or does not exist.

"
end if
else
'Response.Write "Server is up and URL is available.

"
getcustomXML = xmlhttp.responseText
end if
set xmlhttp = nothing


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


> --
> Evertjan.
> The Netherlands.
> (Please change the x'es to dots in my emailaddress)
>

Re: Microsoft.XMLHTTP

"Anthony Jones" wrote:

>
> "Vanessa" wrote in message
> news:465DE78A-6BE7-4703-876D-78785C92B2CA@microsoft.com...
> >
> > "Anthony Jones" wrote:
> > >
> > >
> > > "Vanessa" wrote in message
> > > news:A3A39D92-857B-4F3C-A993-7F1D48076B65@microsoft.com...
> > > > 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.
> > >
> >
> > 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.


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?


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

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

>
> --
> Anthony Jones - MVP ASP/ASP.NET
>
>
>

Re: Microsoft.XMLHTTP

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

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

At first sight I can see nothing seriously wrong with it,
ecxept some superfluous logic

> PostURL = homelink & "CustID.aspx?SearchFlag=PO"

add:

getcustomXML = "" ' initializing

> set xmlhttp = CreateObject("MSXML2.ServerXMLHTTP.3.0")
> on error resume next
> xmlhttp.open "POST", PostURL, false

Why "post"? I would use a "get".

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

"
> elseif status >= 401 and status < 402 then

elseif status = 401 then ' unless you expect numeric fractions: 401.7777

> Response.Write "ERROR: Access denied (401).

"
> elseif status >= 500 and status <= 600 then
> Response.Write "ERROR: 500 Internal Server Error on remote
> site.

"
> else
> Response.write "ERROR: Server is down or does not
> exist.

"
> end if
> else
> 'Response.Write "Server is up and URL is available.

"
> getcustomXML = xmlhttp.responseText
> end if
> set xmlhttp = nothing


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


--
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)

Re: Microsoft.XMLHTTP

"Vanessa" wrote in message
news:77FDBD26-8210-4D18-BD14-F8E57B5214F1@microsoft.com...
>
>
> "Anthony Jones" wrote:
>
> >
> > "Vanessa" wrote in message
> > news:465DE78A-6BE7-4703-876D-78785C92B2CA@microsoft.com...
> > >
> > > "Anthony Jones" wrote:
> > > >
> > > >
> > > > "Vanessa" wrote in message
> > > > news:A3A39D92-857B-4F3C-A993-7F1D48076B65@microsoft.com...
> > > > > 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.
> > > >
> > >
> > > 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.
>
> 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


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

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.

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

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.


--
Anthony Jones - MVP ASP/ASP.NET

Re: Microsoft.XMLHTTP

"Anthony Jones" wrote:

>
>
> "Vanessa" wrote in message
> news:77FDBD26-8210-4D18-BD14-F8E57B5214F1@microsoft.com...
> >
> >
> > "Anthony Jones" wrote:
> >
> > >
> > > "Vanessa" wrote in message
> > > news:465DE78A-6BE7-4703-876D-78785C92B2CA@microsoft.com...
> > > >
> > > > "Anthony Jones" wrote:
> > > > >
> > > > >
> > > > > "Vanessa" wrote in message
> > > > > news:A3A39D92-857B-4F3C-A993-7F1D48076B65@microsoft.com...
> > > > > > 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.
> > > > >
> > > >
> > > > 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.
> >
> > 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
>
>
> >
> >
> > >
> > > > 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?
> > >
> > > >
> > > > > 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.
> > > >
> > >
> > > 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..
>
> 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.
>
> >
> > >
> > > > >
> > > > > 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.
> > > >
> > >
> > > 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.
> >
>
> 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.
>
>
> --
> Anthony Jones - MVP ASP/ASP.NET
>
>
>

Thanks Anthony!! Then I will keep using ServerXMLHTTP for my new project
with ASP -> ASP.NET and see how it goes.

Re: Microsoft.XMLHTTP

"Evertjan." wrote:

> =?Utf-8?B?VmFuZXNzYQ==?= wrote on 15 jul 2007 in
> microsoft.public.inetserver.asp.general:
>
> >
> > 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
> > '....
>
> At first sight I can see nothing seriously wrong with it,
> ecxept some superfluous logic
>
> > PostURL = homelink & "CustID.aspx?SearchFlag=PO"
>
> add:
>
> getcustomXML = "" ' initializing
>
> > set xmlhttp = CreateObject("MSXML2.ServerXMLHTTP.3.0")
> > on error resume next
> > xmlhttp.open "POST", PostURL, false
>
> Why "post"? I would use a "get".
>
> > 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).

"
> > elseif status >= 401 and status < 402 then
>
> elseif status = 401 then ' unless you expect numeric fractions: 401.7777
>
> > Response.Write "ERROR: Access denied (401).

"
> > elseif status >= 500 and status <= 600 then
> > Response.Write "ERROR: 500 Internal Server Error on remote
> > site.

"
> > else
> > Response.write "ERROR: Server is down or does not
> > exist.

"
> > end if
> > else
> > 'Response.Write "Server is up and URL is available.

"
> > getcustomXML = xmlhttp.responseText
> > end if
> > set xmlhttp = nothing
>
>
> >
> > 'use the value from getcustomXML to continue processing.
> > '....
> > '....
>
>
> --
> Evertjan.
> The Netherlands.
> (Please change the x'es to dots in my emailaddress)
>

Thanks Evertjan!!