Hi,

Ours is an ASP.NET 2.0 web application interacting with a third-party web 
service hosted on Tomcat servers.

When client application submits the web request to the web service from the 
Production servers, we observe the frequent occurrence of the error 'The 
request was aborted: The request was canceled. at 
System.Net.HttpWebRequest.GetResponse()'.
The status of the web exception received is ‘RequestCanceled’, which is the 
default status.

In these cases, it is observed that no request from the ASP.NET client is 
hitting the Tomcat servers and the time at which the error is getting logged 
is almost instantaneous after submitting the request. So, it looks like the 
connection to the server is not available when the client application expects 
it to be open.

This issue is affecting our existing customers to a greater extent.
Can you please let us know the cause for this issue and the solution for the 
same? 

Note : From the information available, we understand that one possible 
solution for this issue is - setting ‘HttpWebRequest.KeepAlive = false’. But 
we also understand that this would slow down the process by opening a new 
connection for each request. Hence we are hesitant to follow this approach, 
as our application is live and several customers are currently using it. 
Obviously we do not want to slow down the response times.
Can you please let us know whether setting this ‘KeepAlive’ to ‘false’ be 
advisable and the impact of the same?
--- 
Thanks,
Priya

"TBATravel"  wrote in message 
news:572EABC9-7CB9-4315-BC02-17D2E24E8BD0@microsoft.com...

> Hi,
>
> Ours is an ASP.NET 2.0 web application interacting with a third-party web
> service hosted on Tomcat servers.
>
> When client application submits the web request to the web service from 
> the
> Production servers, we observe the frequent occurrence of the error 'The
> request was aborted: The request was canceled. at
> System.Net.HttpWebRequest.GetResponse()'.
> The status of the web exception received is ‘RequestCanceled’, which is 
> the
> default status.
>
> In these cases, it is observed that no request from the ASP.NET client is
> hitting the Tomcat servers and the time at which the error is getting 
> logged
> is almost instantaneous after submitting the request. So, it looks like 
> the
> connection to the server is not available when the client application 
> expects
> it to be open.


No, it looks like the Tomcat side sees no packets from your client, and like 
your client is failing to communicate with the Tomcat side. Don't assume 
that the connection is unavailable. In fact, don't assume anything yet.

I suggest you take a look at the network traffic between the client and the 
server when the problem occurs. You can start with doing a "tracert" command 
from a Command Prompt window ON THE CLIENT MACHINE as soon as the problem 
occurs. Use "tracert -d <<servername>>" (the "-d" displays the output as 
numeric, without depending on a DNS server to translate it into a host 
name). tracert may give you some idea about your general connectivity at 
that time.

Similarly, try "ping <<servername>>". See if you can get there. If you can, 
great, but if you can't, it's not proof - there could be a firewall or 
something else preventing the ping request from reaching the server or 
preventing the server from responding.

Another trick is to use the old "telnet" command from the Command Prompt 
window. Use:

-----------------------------------
C:> telnet <<servername>> 80
GET /
-----------------------------------

You may not have known this, but HTTP is based on the same protocol as the 
old remote terminal protocol, "telnet". If you telnet to the port your 
server is meant to be listening on, you can manually send a simple HTTP 
request. If you can't connect with telnet, then your client won't be able to 
connect, either. If you _can_ connect, but get an error message when you do 
a "GET /" or "GET /servicepath/servicename.asmx", then your client would 
likely get the same error.

You may try looking at the traffic from the client. I suggest you do so from 
a point on the same network segment as the client, and in fact a location 
physically close to the client. Look to see what, if any, traffic comes from 
the client when the problem occurs. In particular, if there are any 
responses at all to the messages from the client, then it tells you that you 
have connectivity to whatever responded.
-- 
John Saunders [MVP]

Hi John,

Thanks for the response.

As this issue of ‘Request aborted. Request Canceled’ occurs only in the 
Production environment, there are some practical difficulties (due to the 
restricted access) in carrying out the exercise you have suggested. 
There are multiple servers on which the application is hosted and so it is 
not possible to monitor the logs in all the servers continuously and track 
them. 

Moreover, from the analysis done with the available logs, we can observe 
that there are some successful responses almost immediately after the error 
‘Request aborted’ have been logged on the same server.

Let us consider the case below:
- In one of the servers, at TimeStamp 05:30:19 - First request got logged. 
- Immediately at the same time 05:30:19 - 'The request was aborted: The 
request was canceled.  at System.Net.HttpWebRequest.GetResponse()' error got 
logged. 
- The second request got logged at 05:30:20. 
- Proper response for the second request got logged at 05:30:24. 
In this case, as it is evident the request at 05:30:19 got aborted and the 
request at 05:30:20 worked fine. So, as you would agree it is practically not 
possible to try the ‘tracert’, ‘ping’ or ‘telnet’ within one second. 

Please let us know the further possible suggestions / fix for this issue.

We feel that identifying the exact root cause of this issue and fixing it 
may not be immediate.
In the meanwhile, we would like to follow the approach 
‘HttpWebRequest.KeepAlive = false’ as our live customers are severely 
impacted by this issue.
Can you please let us know whether setting this ‘KeepAlive’ to ‘false’ be 
advisable and the impact of the same?

Thanks,
Jp

"John Saunders [MVP]" wrote:


> 
> "TBATravel"  wrote in message 
> news:572EABC9-7CB9-4315-BC02-17D2E24E8BD0@microsoft.com...
> > Hi,
> >
> > Ours is an ASP.NET 2.0 web application interacting with a third-party web
> > service hosted on Tomcat servers.
> >
> > When client application submits the web request to the web service from 
> > the
> > Production servers, we observe the frequent occurrence of the error 'The
> > request was aborted: The request was canceled. at
> > System.Net.HttpWebRequest.GetResponse()'.
> > The status of the web exception received is ‘RequestCanceled’, which is 
> > the
> > default status.
> >
> > In these cases, it is observed that no request from the ASP.NET client is
> > hitting the Tomcat servers and the time at which the error is getting 
> > logged
> > is almost instantaneous after submitting the request. So, it looks like 
> > the
> > connection to the server is not available when the client application 
> > expects
> > it to be open.
> 
> No, it looks like the Tomcat side sees no packets from your client, and like 
> your client is failing to communicate with the Tomcat side. Don't assume 
> that the connection is unavailable. In fact, don't assume anything yet.
> 
> I suggest you take a look at the network traffic between the client and the 
> server when the problem occurs. You can start with doing a "tracert" command 
> from a Command Prompt window ON THE CLIENT MACHINE as soon as the problem 
> occurs. Use "tracert -d <<servername>>" (the "-d" displays the output as 
> numeric, without depending on a DNS server to translate it into a host 
> name). tracert may give you some idea about your general connectivity at 
> that time.
> 
> Similarly, try "ping <<servername>>". See if you can get there. If you can, 
> great, but if you can't, it's not proof - there could be a firewall or 
> something else preventing the ping request from reaching the server or 
> preventing the server from responding.
> 
> Another trick is to use the old "telnet" command from the Command Prompt 
> window. Use:
> 
> -----------------------------------
> C:> telnet <<servername>> 80
> GET /
> -----------------------------------
> 
> You may not have known this, but HTTP is based on the same protocol as the 
> old remote terminal protocol, "telnet". If you telnet to the port your 
> server is meant to be listening on, you can manually send a simple HTTP 
> request. If you can't connect with telnet, then your client won't be able to 
> connect, either. If you _can_ connect, but get an error message when you do 
> a "GET /" or "GET /servicepath/servicename.asmx", then your client would 
> likely get the same error.
> 
> You may try looking at the traffic from the client. I suggest you do so from 
> a point on the same network segment as the client, and in fact a location 
> physically close to the client. Look to see what, if any, traffic comes from 
> the client when the problem occurs. In particular, if there are any 
> responses at all to the messages from the client, then it tells you that you 
> have connectivity to whatever responded.
> -- 
> John Saunders [MVP]
> 
> 
> 

"Jp"  wrote in message 
news:4A89C8B0-8825-43C6-B7B6-BC44214A5BB2@microsoft.com...

> Hi John,
>
> Thanks for the response.
>
> As this issue of ‘Request aborted. Request Canceled’ occurs only in the
> Production environment, there are some practical difficulties (due to the
> restricted access) in carrying out the exercise you have suggested.
> There are multiple servers on which the application is hosted and so it is
> not possible to monitor the logs in all the servers continuously and track
> them.
>
> Moreover, from the analysis done with the available logs, we can observe
> that there are some successful responses almost immediately after the 
> error
> ‘Request aborted’ have been logged on the same server.
>
> Let us consider the case below:
> - In one of the servers, at TimeStamp 05:30:19 - First request got logged.
> - Immediately at the same time 05:30:19 - 'The request was aborted: The
> request was canceled.  at System.Net.HttpWebRequest.GetResponse()' error 
> got
> logged.
> - The second request got logged at 05:30:20.
> - Proper response for the second request got logged at 05:30:24.
> In this case, as it is evident the request at 05:30:19 got aborted and the
> request at 05:30:20 worked fine. So, as you would agree it is practically 
> not
> possible to try the ‘tracert’, ‘ping’ or ‘telnet’ within one second.
>
> Please let us know the further possible suggestions / fix for this issue.
>
> We feel that identifying the exact root cause of this issue and fixing it
> may not be immediate.
> In the meanwhile, we would like to follow the approach
> ‘HttpWebRequest.KeepAlive = false’ as our live customers are severely
> impacted by this issue.
> Can you please let us know whether setting this ‘KeepAlive’ to ‘false’ be
> advisable and the impact of the same?


I haven't used this feature myself, so I can't say. The effect of setting it 
to false should be that the connection between client and server will be 
closed after each request/response pair. There will be the added overhead of 
a new connection being established and torn down for each request.
-- 
John Saunders [MVP]