barkha shah

Hi All,
I would like to implement checking the unhealthy state of ISAPI Extension.
I have read an article related to it
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/iissdk/iis/developernotesforisapiextensions.asp

and got some hint as to how extension can take advantage of this feature.
One is to monitor the status of its internal thread pool.
Q1) Can Any one give me more ideas as when to report an unhealthy state to
IIS.
Q2) How the ServerSupportFunction with HSE_REQ_REPORT_UNHEALTHY works?
Am I right in understanding the following case:

if ( somethingWentWrong)
{
fResult = pECB->ServerSupportFunction(
pECB->ConnID,
HSE_REQ_REPORT_UNHEALTHY,
szReason,
NULL,
NULL);
}
Is it that above code means that ISAPI Extension is declaring itself
unhealthy ? How much time would it take for IIS to recycle the worker
process immediately after above code execution given that ping is enabled.
Is there any code sample that demonstrates the above functionality.

Thanks and Regards
barkha shah

wade a. hilmo [ms]

Hi Barkha,

The purpose of HSE_REQ_REPORT_UNHEALTHY is that an ISAPI can tell IIS that
it's terminally ill and wants its host process recycled.

Frankly, there is very little code out there that can be both terminally
ill, and able to recognize it and do something useful, at the same time.
Whether or not you code can do this is up to you. My personal
recommendation is that you don't go looking for opportunities to use this
API (or any other, really.) When you get to a point in your code where it
is still working properly, yet it can somehow see that it's heading for
disaster, you'll know that it's time to report yourself unhealthy.

I can tell you how ASP uses this feature: ASP uses a pool of threads to
call into the script processor. ASP also supports a script timeout. When
the timeout period elapses, ASP asks the script processor to cancel its work
and return the thread to ASP. This works great if the script processor is
doing work. If, on the other hand, the script processor has called out into
some code outside of it's control (ie. a component invoked on and ASP page),
then it cannot comply with the request to cancel. ASP keeps track of how
many of its threads are in the state where they cannot be cancelled. Once
enough threads are in this state, ASP will report itself unhealthy, due to
the dwindling number of threads available in its pool. This gives IIS a
chance to replace the process hosting ASP, while still allowing requests in
flight a chance to complete gracefully.

Finally, to answer your specific question about timing, this is completely
under administrative control. The recycle event comes right after the
worker process answers a ping from the monitoring piece of W3SVC. The
timing and frequency of the ping can be set in the application pool
properties in MMC. Pinging can also be disabled. If pinging is disabled,
then the recycle due to unhealthy will not occur. Also, if you are in IIS 5
isolation mode, the recycle will not occur.

I hope that this helps,
-Wade A. Hilmo,
-Microsoft

barkha shah

Thanks alot Wade for this rich information.
barkha shah