How to protect application pools from session serialization exceptions?

Question

We\'re using an Out-of-Process Session Provider (ScaleOut) for an ASP.NET application and we\'ve noticed that when an object that\'s not correctly setu

Answer 1

I fixed this by simply removing the SessionEnd methods completely. It isn't enough to remove the contents of the methods as Asp.net searches for the existence of the method using reflection and then runs the offending code.

Answer 2

Can we trap errors that happen at this step to protect the app pool? The exceptions raised here are logged w/ Source=ASP.NET 2.0.50727.0 and don't reach the application error handlers in global.asax. What can we do to guard against this scenario, even after appropriate checks & balances are applied to session-bound objects?

I don't know if this will work, but you can give it a shot

Answer 3

We were able to resolve this issue with the help of SOSS technical support – they were tremendously helpful – here are the details:

• Upon session expiry, SOSS raises an expiration event in its client libraries, which in turn are responsible for firing Session_End in Global.asax (N.B: ScaleOut load balances expiration events across clients, so the web server that created the session may not necesarily receive its expiration event - this is critical for trying to reproduce these issues).
• Because this happens outside the context of a request, the exception is unhandled and kills the app pool;
• It’s an extremely uncommon scenario but one that they will nonetheless address in upcoming maintenance releases;

• The remedies are as follows:

  1. Fix the System.Exception-derived type (that’s serializable but not unserializable);

  2. Remove Session_End events in Global.asax or disable the expiration events (max_event_retries set to 0 in soss_params.txt);

  3. In these scenarios, it’s likely that the user encounters a SerializationException on one of their requests, meaning it reaches Application_Error; here you can clear the session keys (must clear all of them) or abandon the session outright;

  4. Subscribe to AppDomain.UnhandledException to be notified of unhandled exceptions, should they occur (no recourse here, just logging); they can also be disabled via legacyUnhandledExceptionPolicy (not recommended);