IIS ISAPI Filter problem

From: APB (an_at_nomail.com)
Date: 03/25/04 

Date: Thu, 25 Mar 2004 04:58:02 -0800

Here's something that has been taking a lot of my time and I really need
some help before going definitly crazy. The full explanation takes some
time to write so please bare with me.

The ideia is to use an ISAPI Filter in IIS to redirect certain requests
to another server and then send the response back. ( just so that you
know, I need to enable that some Internet requests reach Intranet
servers, in a highly secure environment, i.e. firewalls ). I'm using
VC++ 6.0 with MFCs.

The way I'm doing this is to check the URL for the specific tokens, and
if found, the whole request is re-sent to another server using:
CInternetSession; GetHttpConnection; CHttpFile->OpenRequest;
CHttpFile->SendRequest, etc.

And it works perfectly, except ... if I try the poor man's stress test:
keep the finger on F5 (refresh) for some time, it completly floods IIS
and it apparently hangs (in this case I'm just re-directing to my own
machine, but the results are similar). The problem is with the
SendRequest, because it takes some time before returning the response it
stalls everything.

So, I set the CHttpFile->SendRequest timeout to 10 secs (default is 3
min.). This improved a bit. At least now it started to release the
requests sooner, and it was possible to see that most of the time IIS
doesn't really hang or crash, it is just unable to respond properly. And
after it processes all requests in queue, it (usually) resumes normal
work.

Now, I put a counter in my ISAPI just to know how many requests it would
hold before starting to hang and ... 4/5(!) is the result. That's right,
the maximum amount of concurrent thread acessing my ISAPI is 5(!). No
suprise then that it very quickly stops to respond.

I tried testing with pages that are not redirected (I check the tokens
in the URL and if none if found I exit with a quick
SF_STATUS_REQ_NEXT_NOTIFICATION) and ... it also uses 5 threads max. but
in this case they seem to be sufficient (I tested an ASP page that
returns the time).

My ISAPI entry point is the "OnReadRawData" event. But I also tried with
"OnPreprocHeaders" and the results are the same. Needless to say that I
took great care with multi-threading. All the work is processed in a
separate class that is localy instatiated. The very few global variables
are handled inside Critical Sections.

Why only 5 threads? Where is this set? Can it be increased? As anyone
ever done something similar?

This type of ISAPI is usually common with Application Servers, but
surprinsigly documentation or information on how to do something like
this is frightenly scarse.

Please, someone, anyone, help! Thanks.

Regards
Bruno

*** Sent via Developersdex http://www.developersdex.com ***
Don't just participate in USENET...get rewarded for it!

Relevant Pages

  • Re: ISAPI Filter as Proxy
    ... Filter/Extension DLL, where the Filter DLL matches the requests in question ... SF_NOTIFY_PREPROC_HEADERS, and if it matches, rewrite the URL to the ISAPI ... WinHttp call to the other server (DO NOT USE WININET ON A SERVER -- it is ...
    (microsoft.public.inetserver.iis)
  • Re: ISAPI Filter as Proxy
    ... I basically need to reverse proxy FrontPage publishing requests. ... Filter/Extension DLL, where the Filter DLL matches the requests in question ... SF_NOTIFY_PREPROC_HEADERS, and if it matches, rewrite the URL to the ISAPI ... WinHttp call to the other server (DO NOT USE WININET ON A SERVER -- it is ...
    (microsoft.public.inetserver.iis)
  • Re: Red Hat thread sync question
    ... > If I send lesser number of requests, ... Basically, Ramki, "you were simply lucky" that the application didn't hang ... instead is that each incoming request is placed into a queue. ... A server designed like this will always provide a consistent and reliable ...
    (comp.os.linux.x)
  • Re: Red Hat thread sync question
    ... > If I send lesser number of requests, ... Basically, Ramki, "you were simply lucky" that the application didn't hang ... instead is that each incoming request is placed into a queue. ... A server designed like this will always provide a consistent and reliable ...
    (comp.os.linux.networking)
  • Re: Red Hat thread sync question
    ... > If I send lesser number of requests, ... Basically, Ramki, "you were simply lucky" that the application didn't hang ... instead is that each incoming request is placed into a queue. ... A server designed like this will always provide a consistent and reliable ...
    (comp.os.linux.setup)
Loading