Views: | 15632 |
Number of votes: | 2 |
Average rating: |
This article applies to EPiServer CMS 4.61 and 4.62.
This article describes how to configure multiple EPiServer installations to contact each other when changes to the cache occur. The concept of forwarding cache invalidations is called cache listeners.
Important! The cache listener support requires Web Services to communicate. Make sure Web Services are accessible before you follow this guide. For forms-authenticated sites, refer to the Web Services section in EPiServer SDK.
EPiServer installations can send cache invalidations to other EPiServer installations that either share the same database or use different databases, but share information through Web Services. To understand this concept you must understand how EPiServer separates one page from another.
All pages in EPiServer are identified with a structure that consists of the identification number of the page, the identification number of the working version, and the site name. The site name is just a short name to identify the logical site, the same way you identify a domain in Windows that uses a common user account store. For example, the site www.episerver.com could have the site name “episervercom”. If www.episerver.com had three load-balanced Web sites, all should have the name “episervercom”, because all deliver pages from the same database. Page with ID 30 on site “episervercom” is always the same, irrespective of the load-balanced server delivering it, and should be treated so by EPiServer.
If “episervercom” were to read pages using Web Services from www.ep.se that have another database, they must be separated by the site name. The local site name for www.ep.se is set to “epse”. EPiServer now knows that a page with ID 30 on “episervercom” is not the same as 30 on “epse”.
When you request a page with ID 30 on the site “epse” from the site “episervercom”, the EPiServer data factory must know where to get this page on your network. In Admin mode in EPiServer, you have a user interface to configure remote sites. Here you can specify that “epse” can be contacted at this URL with this user name and password.
“Remote Web sites” in Admin mode is only a way to configure which site names match up with which configurations.
You can configure an EPiServer installation that some of these sites want to listen to on local cache invalidations. For example, if you wish to specify that "epse” should contact “episervercom” every time changes in the cache occur, set the EPsCacheListeners key in web.config to “episervercom”. The actual data will not be transmitted to the remote site. It will only call to tell that this page is no longer valid and should be read from the Web Service or database again.
Sites that share the same database are most often referenced as load-balanced servers. This example shows a common scenario with two servers: Server1 and Server2.
We have a site with URL http://www.domain.com that is installed on both servers. The steps below assume that a user with name “WebServerUser” has been created in the “ntdomain” domain with access to the "WebServices" folder of your EPiServer installation.
Note The names of the sites are case-sensitive. We recommend that you always use lowercase names as used in this sample.
<add key="EPsLocalSite" value="domaincom" />
<add key="EPsCacheListeners" value="domaincom2" />
<add key="EPsCacheListeners" value="domaincom1" />
You have now configured both load-balanced servers to contact each other when parts of the cache must be invalidated. Try creating new pages on one of the servers and the changes should show up on the other server without any noticeable delay.
Some of the sites do not have any signatures set. Verify that all sites have the same identical signature set under Remote Web sites in Admin mode.
All sites do not have the same identical signature. Verify that all sites have the same identical signature set under Remote Web sites in Admin mode.
The site is probably using forms authentication and the credentials are not valid. Check that the credentials you entered are not only valid in Windows, but also valid for the WebServices folder of the site. See the Web Services section in the EPiServer SDK for more information about configuring Windows-authenticated Web Services on a forms-authenticated site.
The URL on the site does not point to a valid site. Open the URL in a Web browser and make sure you can contact it from the actual server. The actual communication is done using a Web Service call from one server to another, either over HTTP port 80 or HTTPS/SSL port 443.
Note Remember to test this locally on the site, not from your local workstation, as other DNS or firewall rules may apply.
Important! Prior to configuring cache listeners, read the Web Services section in EPiServer SDK for background information about configuring Web Services.
The most common error is typing errors. Verify that all site names are identical. Remember that site names are case-sensitive when it comes to pushing cache changes. For example, if Site 1 is named “mysite” and Site 2 is named “MySite” the communication may be valid, but the cache will not get updated as expected.
Make sure that you have also checked the following:
Local Site Name: <%=EPiServer.Global.EPConfig["EPsLocalSite"] %>
My Cache Listeners: <%=EPiServer.Global.EPConfig["EPsCacheListeners"] %>
<%=EPiServer.Global.EPDataFactory.LookupRemoteSite("YourCacheSiteNameFromEPsCacheListeners") == null ? "Site is null" : "Site exists"%>