Yesterday we ran into an odd problem with our load balancers. To give you some history, we use EPiServer Community to handle users and store user attributes. The application works in both http and https depending on where on the site you are at the moment.
You can imagine the look on our faces
We had just deployed our application to a load balanced test environment when the application started to act strange. The problem was that when we saved attributes to a users profile in http the attributes where not updated when going into a part of the site that ran under https. At first we thought that our services where badly configured. As it turned out, we where being sent to different servers depending on the protocol we where using, if we used http we where served by server 1 but when we went to a https page we were served by server 2! The load balancer that should have used sticky sessions was obviously not doing it’s work. But that is a hole other can of worms. That lead us into suspecting that there was a cache not being invalidated correctly. We used the EPiServerRemoteEventsListener tool to check if the EPiServer Cache notification was running as it should. And it did.
After some digging we found that the episerver.common.config file is the key to all caching goodness. The key parts are the cache section. This section should look the same in all servers that are going to be part of the cache notification network.
<episerver.common>
<siteHosts>
<add name="Default" hostUrl="*" connectionStringName="EPiServerCommon" />
</siteHosts>
<sites>
<site hostName="Default">
<cache defaultProvider="EPiServerCacheExpirationProvider">
<providers>
<add name="EPiServerCacheExpirationProvider" type="EPiServer.Common.Cache.CacheExpirationProvider, EPiServer.Common.Cache" />
</providers>
</cache>
As all other major bugs, we found ours in a very small but significant part of the configuration
<replication>
<subscriber serverName="WebServer1" siteName="MySite" port="4123" alternatePort="4321" broadcastAddress="10.130.251.255" />
</replication>
Server 2
<replication>
<subscriber serverName="WebServer2" siteName="MySite" port="4123" alternatePort="4321" broadcastAddress="10.130.251.255" />
</replication>
It turns out that we had the same value for serverName in all servers. The name is as it says the actual DNS name of the server as you would have called it if you where to remote into it. In the other hand, the siteName attribute should be set to the same value in all servers, the same for port, alternatePort and broadcastAdress, which by the way we couldn’t find any documentation on whether we could change it to another address, the same goes for EPiServers own cache notification.
Anyway after changing this setting the app started to work as expected. We where still being redirected to different servers on protocol basis but the cache was being invalidated correctly at both servers.