I'm having a very hard time understanding the terribly written official Sitecore documentation surround session expiration here:


It states (emphasis my own):

The Sitecore Experience platform supports a dedicated server for expired session processing. This means that if you have an environment using a cluster of CD servers, you can configure some of the servers to only serve content, but not to process the expired session state data by using the pollingEnabled setting. The pollingEnabled setting specifies whether to enable processing of expired sessions (default value is true). For example, you can enable it on the CD servers that are dedicated to expired sessions processing and disabled it on the live CD servers, (that serve content to visitors).

And then goes on to warn:

Important You must ensure the servers that are dedicated to expired session processing are not serving content to visitors. For example, if you have configured a load balancer for CD servers, you must ensure requests do not redirect to servers that are dedicated to expired sessions processing.

What on earth is going on here? Can I have 1 or multiple instances processing expired sessions? It's as clear as mud.

Out of the box, a CD serves content. That's why it is called a Content Delivery server. Out of the box, a CD also has pollingEnabled set to true. This means that Sitecore have configured, by default, a CD to also process expired sessions.

But then they say that a CD that is serving content to users must not also process expired sessions, which entirely contradicts the out of the box default setting. It also fails to explain why they have issued this warning. What's going to happen if I fail to prevent their own default settings doing this?

Rant over, here's my question:

What I'm supposed to do in the following scenario:

  • 2 load-balanced CD servers that are serving content
  • Both CDs use redis for private and shared session state
  • No dedicated session expiration server

My deduction is that I should have a single CD with pollingEnabled="true" so that both CDs aren't trying to process the same sessions and submit them to xConnect. Is this right or am I missing something?

  • 1
    I don't think you're that far off. I, too, see the contradiction. I think the best approach is going to be to see how Sitecore uses the pollingEnabled attribute. This means decompiling the Sitecore redis DLL and seeing what that mechanism truly does. This is obviously non-ideal, but it will work.
    – jrap
    Dec 20, 2021 at 14:50
  • 1
    I downloaded Sitecore 10.2 XP Scaled App Service and inspected the CD app service configs and Redis does not have pollingEnabled set to true (in fact the attribute is absent). However, the mssql provider does. Did you misread the config? If not, please update your question with the version you are seeing the improper attribute.
    – jrap
    Dec 20, 2021 at 16:44
  • @jrap I'm just going by what the docs state - that pollingEnabled is "true" by default. This is confirmed by the Anna Gevel's answer below. Thanks for taking the time to look at the configs but I think you just confirmed that it is just using the default (true) which matches the docs.
    – theyetiman
    Dec 21, 2021 at 10:17
  • Yep makes sense.
    – jrap
    Dec 21, 2021 at 11:25

2 Answers 2


I agree it is confusing, but this article is only applicable to the scenario when you want to separate Content Delivery and Expired session processing roles.

Your desired setup (2 CDs and no dedicated session expiration server) can be achieved with the following configuration:

  • Both CDs should be included in load balancing
  • Both CDs should have private and shared session configured
  • Both CDs should have pollingEnabled="true" (if this parameter is omitted, "true" will be used by default)

This type of setup comes out-of-the-box with Sitecore XP Scaled packages as by default all CD instances can serve content and process expired sessions.

  • Thanks - so just to confirm, multiple instances processing expired sessions is OK? They won't process the same sessions simultaneously and cause problems?
    – theyetiman
    Dec 21, 2021 at 10:19
  • 1
    No, they won't, you can have multiple instances with pollingEnabled="true".
    – Anna Gevel
    Dec 21, 2021 at 13:58

@Anna's answer is correct. However, I did some additional digging and can add a bit of context to her answer in case it helps others.

Every time Sitecore writes session data to Redis it consists of two pieces (basically): Data and Internal


Example Redis key: {private_05f8ddd4-b1c9-4a17-89bd-f0356b561713}_Data

This key contains the substance of a session, in this case, the private session. Shared sessions have the same format. If you request the value of this key (hgetall ) you will receive messy-looking session data. Sitecore is able to comprehend it, but that's for a different topic.


Example Redis key: {private_05f8ddd4-b1c9-4a17-89bd-f0356b561713}_Internal

This key is a compliment to the Data key. It uses the same SessionID prefix. Instead of holding session object data, it holds metadata:

Session Internal Meta Data

Session Expiration Logic

The logic Sitecore uses to remove expired sessions can be summarized as

"Every <pollingInterval> seconds, Sitecore queries Redis for Internal suffixed keys with expiration values greater than the defined session timeout limit. If any are found, it then sends a command to delete the Data and Internal keys."

So by default, it checks every 2 seconds for expired sessions and then removes them. Remember, since the Data and Internal keys rely on the same SessionID, it can read the metadata (Internal) and then send an update to delete both the Data and Internal keys from storage.

Why is this useful?

It is interesting that Sitecore does not provide guidance on when to consider this architecture (at least none I could find).

Let's think about how this operates. If we have 10 CD servers deployed with default settings, we know that we are sending 10 calls to Redis every 2 seconds asking for expired sessions. With Redis being a single-threaded/synchronous application this could potentially logjam your Redis instance. I imagine you would need far greater than 10 CD's... possibly 100+ for it to really impact.

Therefore, if you feel Redis is not as responsive as you expect, you could consider adding a dedicated session expiration server to allow you to add more CD servers without affecting Redis performance.

  • Thanks for this insight, it's really useful. I agree that many CD servers could overload the redis server. That seems far more likely than each CD server being overwhelmed by processing expired sessions, which contradicts Sitecore's implication of needing a dedicated session expiration instance. In your hypothetical scenario of 100 CDs do you think that means one is best off to disable pollingEnabled on 99 of them and leave it enabled on 1? Then you don't have to care about configuring and maintaining an extra instance just for session expiration. Seems pointless to me 🤷‍♂️
    – theyetiman
    Dec 22, 2021 at 9:21
  • I think the idea is that you would deploy one cluster of CDs for content- this cluster has a defined app service tier and horizontal scaling that matches your traffic patterns. Then, you can have a much cheaper single CD server for clearing sessions. The only reason you need a full CD server for this is for the initialization of the feature (which takes place during <initialization>... it sets a timer to fire the polling. All other features of the CD are unused. This is very similar to the original method of setting up a processing server (from like 5+ years ago).
    – jrap
    Dec 22, 2021 at 13:11
  • The remaining oddity is why Sitecore felt it was necessary to call out "You must ensure the servers that are dedicated to expired session processing are not serving content to visitors.". I see nothing in my findings that explain why this is a critical step- as like you said, the default is to have all of them do the work anyways.
    – jrap
    Dec 22, 2021 at 13:12

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.