Alfresco Share Cluster – tweaks

I recently faced an upgrade from a single node Alfresco into a high available (HA) configuration (1 Load-Balancer, 2 Alfresco Nodes, 2 Share Nodes) using Alfresco Enterprise 3.4.2 (including kerberos SSO etc.).

The Basic steps (@see Kevs blog post http://blogs.alfresco.com/wp/kevinr/2011/07/28/using-apache-to-load-balance-alfresco-share-with-an-alfresco-repository-cluster-and-clustering-alfresco-share/) went well & my new system performed well. But then I realized that changes to a Share dashboard weren’t visible on the other Share instance. I forget to add the following configuration (“custom-slingshot-application-context.xml”):

But now my Share instances were very slow (dashboard layout changes weren’t visible on the other Share instance either). Loading a dashboard in the browser took up to 8s – without that cache disabling ~2s. Thus I made some tests with a vanilla 3.4.2 & 3.4.6 system and observed the same behavior (not as slow because I didn’t created a few hundred sites & >2000 users in my local system).

First of all I backported the 4.0.c org.springframework.extensions.webscripts.RequestCachingConnector that improved the whole Share performance a little bit. Afterwards I thought about the situations when a cached SURF object must be invalidated and reloaded via its remote store. AFAIK the only moment is when a dashboard configuration is changed on another Share instance. As my configuration only incorporates 2 Share instances I developed the follwing simple tweak to notify the other Share instance if a dashboard config is changed & the Surf object cache should be invalidated:

    re-enable caching for component & pages

  1. add a new HTTP endpoint (used to notify the other Share instance via HTTP if the SURF caches should be invalidated):

  2. append the following lines to site-webscripts\org\alfresco\components\dashboard\customise-dashboard.post.json.js:

  3. added a new Java-backed webscript (Share) mapped to URI api/fme/cache with following executeImpl():

The following things should be kept in mind:

  • this scenario only works with 2 Share instances & has to be enhanced if you’ve more than 2 nodes
  • api/fme/cache is not secured via an authenticator …

I’ll fill (& link) a detailed jira issue shortly.