Exception on a CM server: The session ID is longer than the maximum limit

Question

I am seeing the following error in the logs for the CM I am setting up for one of our clients, in preparation for launch of their Sitecore 8.1u2 site:

Logged Error:

4972 16:30:56 ERROR Sitecore.Analytics.Tracker Cannot start analytics Tracker

Stack trace:

Exception: System.Web.HttpException
Message: The session ID is longer than the maximum limit of 80 characters. Session ID=DictionaryDataReferringSiteDatacm.myclientsname.clientabbrev-prd-cm1.mydelphic.com
Source: System.Web
   at System.Web.SessionState.SessionIDManager.CheckIdLength(String id, Boolean throwOnFail)
   at System.Web.SessionState.InProcSessionStateStore.DoGet(HttpContext context, String id, Boolean exclusive, Boolean& locked, TimeSpan& lockAge, Object& lockId, SessionStateActions& actionFlags)
   at System.Web.SessionState.InProcSessionStateStore.GetItem(HttpContext context, String id, Boolean& locked, TimeSpan& lockAge, Object& lockId, SessionStateActions& actionFlags)
   at Sitecore.Analytics.Data.Dictionaries.DictionaryData.Session.SessionDictionaryData.LoadAs[T](Object key)
   at Sitecore.Analytics.Data.Dictionaries.TrackingDictionary`2.Get(TKey key, LookupStrategy strategy)
   at Sitecore.Analytics.Pipelines.TrafficTypes.ReferringSite.Process(TrafficTypeArgs args)
   at (Object , Object[] )
   at Sitecore.Pipelines.CorePipeline.Run(PipelineArgs args)
   at Sitecore.Analytics.Pipelines.TrafficTypes.TrafficTypePipeline.Run(TrafficTypeArgs args)
   at Sitecore.Analytics.Pipelines.CreateVisits.SetTrafficType.Process(CreateVisitArgs args)
   at (Object , Object[] )
   at Sitecore.Pipelines.CorePipeline.Run(PipelineArgs args)
   at Sitecore.Analytics.Pipelines.CreateVisits.CreateVisitPipeline.Run(CreateVisitArgs args)
   at Sitecore.Analytics.Tracking.StandardSession.CreateInteraction(HttpContextBase httpContext)
   at Sitecore.Analytics.Pipelines.InitializeTracker.CreateVisit.Process(InitializeTrackerArgs args)
   at (Object , Object[] )
   at Sitecore.Pipelines.CorePipeline.Run(PipelineArgs args)
   at Sitecore.Analytics.Pipelines.InitializeTracker.InitializeTrackerPipeline.Run(InitializeTrackerArgs args)
   at (Object , Object[] )
   at Sitecore.Pipelines.CorePipeline.Run(PipelineArgs args)
   at Sitecore.Analytics.Pipelines.StartTracking.StartTrackingPipeline.Run(StartTrackingArgs args)
   at Sitecore.Analytics.DefaultTracker.StartTracking()

The error is basically telling me that the Session ID that was supplied, DictionaryDataReferringSiteDatacm.myclientsname.clientabbrev-prd-cm1.mydelphic.com (note that while the Session ID I am showing you is not the real one, I did make sure that it is the same length and structure as the real one), is longer than the 80-character maximum.

Observations:

I can see that the length of the Session ID is, in fact, longer than 80 characters. I did a little digging and found the Sitecore.FXM.Pipelines.ChooseSessionIdManager.FXMSessionIdManagerProcessor processor of the <getSessionIdManager> pipeline, but I'm not using FXM, so I want to use the default SessionIDManager. Aside from adding my own processor to this pipeline, I don't see any way to control the Session ID value, beyond changing the host name of the site, since the host name is being included in the URL.

Questions:

Is anyone else familiar with this error and how to fix it? Is there another way, beyond changing the host name of the site? Should this issue even be relevant for a CM instance?

Answer 1

Defect explanation

The problem is not the SessionIDManager. It enforces a maximum ID length of 80 characters and you shouldn't attempt to overcome this limitation, since some session state providers may rely on it.

The actual problem is Sitecore's current implementation of SessionDictionaryData. In Sitecore 8.0, this class used to store a dictionary object in the current private session and accessed the whole dictionary using a constant session key. In Sitecore 8.1, this was changed and every dictionary entry is now stored as a separate session (a shared session, to be precise). This was probably done for the sake of easy per-entry expiration.

Take a look at this (reformatted) line of code from SessionDictionaryData.LoadAs<T>(object key):

SessionStateStoreData sessionStateStoreData =
    this.provider.GetItem(
        this.HttpContext,
        "DictionaryData" + typeof (T).Name + key,
        out locked,
        out lockAge,
        out lockId,
        out actions);

The session ID is formed by concatenating:

1. "DictionaryData";
2. The type name of the object being stored—in your case, ReferringSiteData;
3. The dictionary key—in this instance, it's the name of the referring site.

There is no restriction on the length of the key here. So there will always be a possibility for a referring site name to be too long to be stored in this dictionary. Until this defect is fixed, that is.

In your scenario, the referring site name was the domain name of the CM. Changing the domain name will only help with your current situation; other referring sites on the web can still have long domain names.

Solutions

1. Workaround

Well, first of all, this will very rarely be an issue in production. Domain names that long are pretty uncommon, so most users will never experience this error. Using a shorter domain name for your CM will "solve" the error in your environment.

2. Use another dictionary implementation

The current dictionary is injected from the configuration. It is obtained via the getDictionaryDataStorage pipeline:

Sitecore.Analytics.config

<getDictionaryDataStorage>
  <processor type="Sitecore.Analytics.Data.Dictionaries.DictionaryData.Xdb.GetDictionaryDataProcessor, Sitecore.Analytics" />
</getDictionaryDataStorage>

Sitecore.Analytics.Tracking.config

<getDictionaryDataStorage>
  <processor type="Sitecore.Analytics.Data.Dictionaries.DictionaryData.Session.GetDictionaryDataProcessor, Sitecore.Analytics" patch:before="processor[@type='Sitecore.Analytics.Data.Dictionaries.DictionaryData.Xdb.GetDictionaryDataProcessor, Sitecore.Analytics']" >
    <DictionaryData type="Sitecore.Analytics.Data.Dictionaries.DictionaryData.Session.SessionDictionaryData, Sitecore.Analytics" singleInstance="true">
      <param desc="configuration" ref="tracking/sharedSessionState/config" />
    </DictionaryData>
  </processor>
</getDictionaryDataStorage>

You can just remove the second processor (that uses SessionDictionaryData) and then xDB will default to using a MongoDbDictionary instead.

If you don't want your dictionary data to be stored in MongoDB, you can also implement your own dictionary and inject it using the getDictionaryDataStorage pipeline.

3. Wait for an official fix

I registered this bug with Sitecore Support. I'll update this answer if they get back to me with a hotfix.