Challenge 2: Application Pool Isolation and Recycling — Solution Walkthrough

Why the other client's application is likely unaffected:

IIS runs each Application Pool as its own separate worker process
(w3wp.exe). Because the two client applications are described as
being hosted separately, they're almost certainly running in two
different Application Pools, each with its own dedicated worker
process and its own memory space. A memory leak inside one pool's
worker process grows that process's own memory usage — it doesn't
reach into a different pool's separate worker process, so the second
client's application keeps running normally even as the first one's
memory usage climbs.

What recycling would do about the leak:

IIS can be configured to automatically recycle an Application Pool's
worker process — shutting it down and starting a fresh one — on a
schedule or once memory usage crosses a configured threshold.
Recycling doesn't fix the underlying leak in the application's own
code, but it resets the worker process's memory usage back to a
baseline periodically, which is often enough to keep a slow leak from
ever becoming severe enough to cause real problems, buying time until
the actual leak is fixed in the application.

WHY THIS WORKS AS AN ANSWER
------------------------------
This exercise is a direct, concrete application of this chapter's own
IIS section — correctly identifying that isolation happens at the
Application Pool boundary, and that recycling is a mitigation rather
than a fix, mirrors the exact distinction the chapter draws between
"resilience against a leaking application" and "solving the leak
itself."