Web service call timeout

[JD]

We have two web service machines. Call one WS1 and the other WS2. They are
seperated by a firewall. WS1 handles web service calls and also calls web
services provided by WS2. Both machines do not get updated or restarted very
often. The problem is after some period of time, the web service call from
WS1 (within the ASP.NET process) to WS2 hangs and times out.

If I go to WS1 and open IE, I can get the WSDL from WS2, and if I use
another client on WS1 I can actually make the web service call successfully
to WS2 that fails within WS1 ASP.NET process. If I restart the WS1 ASP.NET
process, it starts working again.

I put in a web page that will be housed within the ASP.NET process on WS1.
It allows me to enter URLs and allows me to specify HTTP or TCP. When WS1
ASP.NET process gets into this state, I can enter the URL to WS2 and specify
HTTP, and it gives me the timeout. If I specify TCP it works. If I specify
any URL other than WS2, and specify HTTP or TCP, it works. So it seems
something in the HTTP library gets deadlocked and its associated with a
specific URL.

At first I thought it might be HTTP keep-alive. I configured IIS on WS1 and
WS2 to not use HTTP keep-alive and it continued to show up.

Any ideas?

TIA.
JD

 

[JD]

First thanks for replying.

Unfortunately I cannot provide the detailed debugging information at this
time. What I can tell you is that I get a generic timeout message, and there
is *NO* callstack but an uninterpreted HRESULT returned as the error. I can
also tell you this functionality will work for weeks on end but suddenly
stop working.

I can definitely tell you its the call from WS1 toWS2, and using HTTP not
just web services. When WS1 ASP.NET process gets into this state, I cannot
do a simple HTTP request to WS2 from within the ASP.NET process, I get the
error mentioned above. Try connecting to WS2 from within the ASP.NET process
using TCP and it connects. Change it back HTTP, it fails. Try another URL
with HTTP and its a success. Change it back to WS2 with HTTP, it fails. Try
connecting to WS2 using IE from WS1 and it succeeds. So its process specific
not machine specific, and its protocol specific.

I watched all the port activity with TCPView when the ASP.NET process is in
this state, and all connections are visible except HTTP calls to WS2 from
within the ASP.NET process. TCP connections from within the ASP.NET process
to WS2 do show. IE to WS2 connections do show. This leads me to believe that
the call is blocked within the ASP.NET process itself, and its probably
within the HTTP library since no web service calls or HTTP reqeusts work,
but the TCP connections work.

When I kill the ASP.NET process and it starts again, TCPView will start
showing the HTTP connections to WS2 and all is fine.

At this point I'm just trying to hear if anyone else has heard of this. I
did hear something about HTTP keep-alive causing deadlocks in the HTTP
library but that was a deadend in my case.

If you haven't heard of this or seen this, don't sweat it. I'll probably
wait till it happens again, debug the asp.net process, grab all the
information when the exception is thrown, and start communicating to MS.

JD