«

I have a web service that hits a database and generates a generic list
to be returned to the caller. Currently there are 45 items in that
list. The database response time is negligable and everything is
wrapped in a try/catch, return an empty list.

When I run the client from my perl script (whic is running under
CentOS 5.3), I can execute it countless times (>50) consecutively.
Basically, it runs as fast as I can hit up and then enter. So, I have
it set as a cronjob to run once every 3 minutes. This process runs on
3 machines. So, at max, is web service gets 3 hits per minutes. Now,
with cron, it usually all comes in roughly at the same time. So the
real access is 3 hits in 1 second, every 3 minutes.

Anyway, if I let this thing run for an hour or so the web service just
hangs. If I run the script manually, it will time out after 60
seconds (the timeout value I have set inside of the SOAP::Lite
request).

So, I stop all of the jobs, wait 10 minutes, and the .net web services
are still in a hung state. Running netstat on all machines (including
IIS) shows no active connections on the web service port (it's not
using port 80, rather a custom port). Looking into the IIS logs there
are a number of requests and it just stops. So obviously it's not
logging the failures because it's not getting to that point.

I have tweaked the machine.config based on some other articles,
without success.

<processModel autoConfig="false" maxWorkerThreads="200"
maxIoThreads="100" minWorkerThreads="100" />

and in the web.config

<httpRuntime executionTimeout="60" />

Two things that stick out from the MS site is A) HTTP 1.1 allowing
only two connections (thus the chance to the machine config) and B)
editing the timeout for the web service from the calling script.

I would think that there should be a better alternative than making
the caller behave properly as web service servers should be a little
more hardened against bad client code. I already run all of the
virtual sites/directories in seperate app pools. The server has
plenty of ram/cpu and the affected web service is only consuming 40mb
ram (as it's the only w3c process running at this point).

So what I missing? How can I prevent a possible rouge calling script
from killing my IIS instance?