Jetspeed Cluster Configuration

Jetspeed is an enterprise portal capable of running in clustered application servers. There are several configuration changes required fro running in a clustered deployment:

  1. Use Database Page Manager
  2. Use the Versioned Deployment Manager
  3. Enable Distributed Caching

1. Database Page Manager

PSML represents the pages in your portal. There can be lots of them. The default implementation stores the PSML files on the file system. A secondary implementation stores the files in the database. Storing in the database is necessary when deploying to a clustered Jetspeed distribution, or when you have tens of thousands of users where performance is required. Provided in the alternate directory is a DBPSML alternate configuration, db-page-manager.xml. You can take this file and copy it into your overrides directory. It will override the page-manager.xml beans by name.

 <bean id="org.apache.jetspeed.page.PageManagerImpl" 
        name="pageManagerImpl"
        init-method="init"
        class="org.apache.jetspeed.page.impl.DatabasePageManager">
      <!-- OJB configuration file resource path -->
      <constructor-arg index="0"><value>JETSPEED-INF/ojb/page-manager-repository.xml</value></constructor-arg>       
      <!-- permissions security enabled flag, default=false -->
      <constructor-arg index="1"><value>false</value></constructor-arg>
      <!-- constraints security enabled flag, default=true -->
      <constructor-arg index="2"><value>true</value></constructor-arg>
      <!-- folder/page/link cache -->
      <constructor-arg index="3"><ref bean="pageManagerOidCache"/></constructor-arg>
      <!-- folder/page/link path cache -->
      <constructor-arg index="4"><ref bean="pageManagerPathCache"/></constructor-arg>
  </bean>

2. Versioned Deployment

The default Jetspeed Deployer, although it works well for development on Tomcat, doesn't work well in clustered environments. We have implement a second, Versioned Portlet Application Manager for clustered environments. The Node Manager implementation will most likely be deprecated in the future. We are running into limitations with the NodeManager-based cluster support when deploying to clusters with replicated databases as well as replicated app servers. The default PAM (Portlet Application Manager) is not-appropriate for many deployments of the portal. This second version of the PAM has no listeners, and a simpler deployment algorithm based on a version number supplied in the jetspeed-portlet.xml metadata If this field is not found, or if it is equal to or less than the version in the database, then the PA will not be deployed. This will allow for dropping in 2..n PAs in a cluster, without re-registering. The problem with re-registering is that the registry algorithm deep deletes the old PA def from the database, create a new PA, with all new OIDs, invalidating all other PAs and portlets on other nodes in the cluster.

<bean id="deployFactory" class="org.apache.jetspeed.tools.deploy.JetspeedDeployFactory"/>

<bean id="org.apache.jetspeed.tools.pamanager.PortletApplicationManager" 
  	   class="org.apache.jetspeed.tools.pamanager.VersionedPortletApplicationManager" init-method="start" destroy-method="stop"
  >  	   
  	   <constructor-arg><ref bean="portletFactory"/></constructor-arg>
  	   <constructor-arg><ref bean="org.apache.jetspeed.components.portletregistry.PortletRegistry"/></constructor-arg>
  	   <constructor-arg><ref bean="org.apache.jetspeed.components.portletentity.PortletEntityAccessComponent"/></constructor-arg>
  	   <constructor-arg><ref bean="org.apache.jetspeed.container.window.PortletWindowAccessor"/></constructor-arg>
  	   <constructor-arg><ref bean="org.apache.jetspeed.security.PermissionManager"/></constructor-arg>       
  	   <constructor-arg><ref bean="org.apache.jetspeed.search.SearchEngine"/></constructor-arg>              
  	   <constructor-arg><ref bean="org.apache.jetspeed.security.RoleManager"/></constructor-arg>                     
       <!-- role principals to assign a default permission(s) during deployment of a Portlet Application -->
       <constructor-arg >
         <list>
            <value>user</value>
         </list>
       </constructor-arg>

       <!--  application root -->
        <constructor-arg>
            <value>${applicationRoot}</value>
        </constructor-arg>


   <!-- optional configuration for automatic creation of not yet existing roles as defined in the deployed web.xml:
       <property name="autoCreateRoles"><value>true</value></property>
   -->      
   <!-- optional descriptor change monitor check interval in seconds (0: disabled, default: 10):
       <property name="descriptorChangeMonitorInterval"><value>10</value></property>
   -->
   <!-- optional max PA start retries in case of an error registering ths PA (0: do not retry, default: 10):
   		this was introduced because of DB constraint validation errors in clustered environments
   		see https://issues.apache.org/jira/browse/JS2-666
       <property name="maxRetriedStarts"><value>10</value></property>
   -->
  </bean>

You can find these alternate Spring configurations in the alternate directory is a deployment alternate configuration, deployment.xml. You can take this file and copy it into your overrides directory. It will override the deployment.xml beans by name.

3. Distributed Cache

In a cluster, Jetspeed keeps all internal caches synchronized across the cluster using a distributed cache. Documentation on the Distributed Cache is found here.