June 2010 Entries
When we recently upgraded our project from VS 2008 to VS 2010 everything went just fine. The project was converted and the conversion log didn't report any errors. Two days ago we deployed our web application to the production servers, that's when the problems started to show up.
The application couldn't connect to several services. The error was that the Web Reference URL to the services had been changed from https to http. We hadn’t caught this error in our test environment because the https restriction was not there in that environment.
So if you have converted a project from Visual Studio 2008 to Visual Studio 2010 and you have any web service references that goes to a https endpoint, be sure to check that it hasn’t been changed to https.
I have filed a bug report to the Visual Studio team at Microsoft, so if you get the same problem go there and vote it up, then maybe we can get a solution to it sooner then later.
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.