Tuesday, July 5, 2016

Sitecore session errors with MongoDB

An interesting issue was reported on a Sitecore environment where users were able to browse to several pages, but eventually the website would stop responding to requests (and it appeared as if the server was too busy to respond). However if cookies were cleared on the user's machine, they could browse for a bit before not getting requests back again.

In this instance the shared/private sessions were being stored in MongoDB. The following error was appearing in the logs:
ERROR Application error.
Exception: System.Web.HttpException
Message: Exception of type 'System.Web.HttpException' was thrown.
Source: System.Web
   at System.Web.HttpAsyncResult.End()
   at System.Web.HttpApplication.AsyncEventExecutionStep.OnAsyncEventCompletion(IAsyncResult ar)
Nested Exception
Exception: MongoDB.Driver.MongoDuplicateKeyException
Message: WriteConcern detected an error ''. (Response was { "ok" : 1, "code" : 11000, "err" : "E11000 duplicate key error collection: session.sessions index: _id_ dup key: { : { s: \"j0lvazyxndl5ihfldr0zzce2\", a: \"private\" } }", "n" : NumberLong(0), "updatedExisting" : false }).
Source: MongoDB.Driver
In our instance we traced the error back to a corrupted MongoDB instance (which is a post for another day), and we moved sessions over to SQL Server to resolve the issue. However if you are seeing this error these are some configurations to check.
  1. Inside the web.config the <sessionState> element is where private sessions are defined.
  2. Inside Sitecore.Analytics.Tracking.config file is where shared sessions are defined
  3. Inside ConnectionString.config is where the connection string for any session databases (MongoDB or SQL Server) should be.
If any of these session configurations are using InProc in an environment with multiple servers (content delivery scaled environments for example) you will have a problem if the load balancer is not using sticky sessions (ensuring the visitor always visits the same server). In these sorts of environments its recommended to use a shared session source (MongoDB or SQL Server).


  1. Could you expand on the statement "corrupted MongoDB instance" - I am seeing a lot of these errors but there's nothing wrong with my Mongo from what I can tell. I figure the tracking code on both CD boxes are deciding that they are the the first to write the session record. Any further insights into this issue might help me.


    1. Do you have multiple content delivery servers and if so are they behind a load balancer (sticky or not)?