7.9 - A safeguard to prevent system failures due to wrong (not thread-safe) components

Sometimes we can find a thread safety issue in hst component implementations, which may cause system downtime.
Even if the fact that hst components must be thread safe is probably well known to most developers, some programmers still tend to have non-thread-safe members in their component implementation. Even worse, if they store HstRequest instance as member, then it causes to store HstRequestContext and a lot of stateful provides such as CachingObjectConverter implementation as well, for instance. This can simply cause memory leak.

In order to guarantee more availability, we can dispose everything of HstRequestContext in the CleanupValve, and mark it as 'invalid state'. So CleanupValve can invoke MutableHstRequestContext#dispose(), for example.
Then, we can prevent the worst case scenario at least even if there were clumsy implementations.
And possibly HstRequestContext invocations can check its invalidity and give exceptions about that like 'oh you probably stored an invalid request context, meaning you're totally unaware the thread safety requirement of hst component!'.