Sitecore 8 Shared Session Configuration Pitfall

Sitecore 8 has a wonderful new feature where you can configure a Shared session state provider instead of using the default InProc provider.  You can read more about it here: https://doc.sitecore.net/Sitecore%20Experience%20Platform/xDB%20configuration/Session%20state#_Toc396298780

It may sound obvious, but you should take care in configuring this in a standard production deployment where you have a Content Management (CM) server and 2 Content Delivery (CD) servers.  You must take care to not use the same session database for both the CM and the CD environments.  Why?  Consider the following scenario where you do…

If I have my CD server’s happily running along, and I then need to do a deployment to the CM server for an upcoming release, when you deploy to CM, your assemblies will no longer match the assemblies on the CD servers.  Now consider what happens on session end.  When ASP.NET decides to call the System.Web.HttpApplicationFactory.FireSessionOnEnd method, your app will then serialize all necessary assemblies along with the data that needs to be stored in session.  If there is a difference in the assemblies, or absence of an assembly between one server to the next, your application will terminate with a similar error to the following:

ERROR Unhandled exception detected. The ASP.NET worker process will be terminated.

Exception: System.Runtime.Serialization.SerializationException

Message: Unable to find assembly ‘Sitecore.Support.405652, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null’.

Source: mscorlib

   at System.Runtime.Serialization.Formatters.Binary.BinaryAssemblyInfo.GetAssembly()

   at System.Runtime.Serialization.Formatters.Binary.ObjectReader.GetType(BinaryAssemblyInfo assemblyInfo, String name)

   at System.Runtime.Serialization.Formatters.Binary.ObjectMap..ctor(String objectName, String[] memberNames, BinaryTypeEnum[] binaryTypeEnumA, Object[] typeInformationA, Int32[] memberAssemIds, ObjectReader objectReader, Int32 objectId, BinaryAssemblyInfo assemblyInfo, SizedArray assemIdToAssemblyTable)

   at System.Runtime.Serialization.Formatters.Binary.__BinaryParser.ReadObjectWithMapTyped(BinaryObjectWithMapTyped record)

   at System.Runtime.Serialization.Formatters.Binary.__BinaryParser.Run()

   at System.Runtime.Serialization.Formatters.Binary.ObjectReader.Deserialize(HeaderHandler handler, __BinaryParser serParser, Boolean fCheck, Boolean isCrossAppDomain, IMethodCallMessage methodCallMessage)

   at System.Runtime.Serialization.Formatters.Binary.BinaryFormatter.Deserialize(Stream serializationStream, HeaderHandler handler, Boolean fCheck, Boolean isCrossAppDomain, IMethodCallMessage methodCallMessage)

   at System.Runtime.Serialization.Formatters.Binary.BinaryFormatter.Deserialize(Stream serializationStream, HeaderHandler handler, Boolean fCheck, IMethodCallMessage methodCallMessage)

   at System.Web.Util.AltSerialization.ReadValueFromStream(BinaryReader reader)

   at System.Web.SessionState.SessionStateItemCollection.ReadValueFromStreamWithAssert()

   at System.Web.SessionState.SessionStateItemCollection.DeserializeItem(String name, Boolean check)

   at System.Web.SessionState.SessionStateItemCollection.DeserializeItem(Int32 index)

   at System.Web.SessionState.SessionStateItemCollection.get_Item(Int32 index)

   at System.Web.Util.AspCompatApplicationStep.AnyStaObjectsInSessionState(HttpSessionState session)

   at System.Web.HttpApplicationFactory.FireSessionOnEnd(HttpSessionState session, Object eventSource, EventArgs eventArgs)

   at System.Web.Util.WorkItem.CallCallbackWithAssert(WorkItemCallback callback)

   at System.Threading.ExecutionContext.RunInternal(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)

   at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)

   at System.Threading.QueueUserWorkItemCallback.System.Threading.IThreadPoolWorkItem.ExecuteWorkItem()

   at System.Threading.ThreadPoolWorkQueue.Dispatch()

The assembly mentioned may differ from above, but the concept is the same.  Because the assembly wasn’t able to be serialized on one of the servers, the application was taken down.

One thought on “Sitecore 8 Shared Session Configuration Pitfall

Add yours

  1. I wonder what’s in your session that causes this as I currently have an environment with 1 CM and 2+ CDs that actually at this very moment differ in terms of assemblies… and I don’t have this exception anywhere. And they’re all humming along on the same session provider using the same underlying storage…

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Blog at WordPress.com.

Up ↑

%d bloggers like this: