Chapter 8. Clustering Configuration - JBoss Portal 2.4 Reference Guide 英文版参考指南文档

JBoss Portal leverages various clustered services that are found in JBoss Application Server. This section briefly details how each is leveraged:

When you want to run JBoss Portal on a cluster there are a few things to keep in mind:

We are going to outline how to setup a two node cluster on the same machine in order to test JBoss Portal HA. The only missing part from the full fledged setup is the addition of a load balancer in front of Tomcat. However a lot of documentation exist on the subject. A detailed step by step setup of Apache and mod_jk is available from the JBoss Wiki.

As we need two application servers running at the same time, we must avoid any conflict. For instance we will need Tomcat to bind its socket on two different ports otherwise a network conflict will occur. We will leverage the service binding manager this chapter of the JBoss AS documentation.

The first step is to copy the all configuration of JBoss into two separate configurations that we name ports-01 and ports-02 :

>cd $JBOSS_HOME/server
>cp -r all ports-01
>cp -r all ports-02

Edit the file $JBOSS_HOME/server/ports-01/conf/jboss-service.xml and uncomment the service binding manager :

<mbean code="org.jboss.services.binding.ServiceBindingManager"
   name="jboss.system:service=ServiceBindingManager">
   <attribute name="ServerName">ports-01</attribute>
   <attribute name="StoreURL">${jboss.home.url}/docs/examples/binding-manager/sample-bindings.xml</attribute>
   <attribute name="StoreFactoryClassName">org.jboss.services.binding.XMLServicesStoreFactory</attribute>
</mbean>

Edit the file $JBOSS_HOME/server/ports-02/conf/jboss-service.xml, uncomment the service binding manager and change the value ports-01 into ports-02:

<mbean code="org.jboss.services.binding.ServiceBindingManager"
   name="jboss.system:service=ServiceBindingManager">
   <attribute name="ServerName">node-02</attribute>
   <attribute name="StoreURL">${jboss.home.url}/docs/examples/binding-manager/sample-bindings.xml</attribute>
   <attribute name="StoreFactoryClassName">org.jboss.services.binding.XMLServicesStoreFactory</attribute>
</mbean>

Setup a database that will be shared by the two nodes and obviously we cannot use an embedded database. For instance using postgresql we would copy the file portal-postgresql-ds.xml into $JBOSS_HOME/server/ports-01/all and $JBOSS_HOME/server/ports-02/all.

Copy JBoss Portal HA to the deploy directory of the two configurations.

JBoss Cache Configuration Note : To improve CMS performance JBoss Cache is leveraged to cache the content cluster wide. We recommend that you use the following version of JBoss Cache for best performance:

When building from source the following command: {core}/build.xml deploy-ha automatically upgrades your JBoss Cache version.

Alternative: If upgrading your JBoss Cache version is not an option, the following configuration change is needed in the jboss-portal-ha.sar/portal-cms.sar/META-INF/jboss-service.xml. Replace the following configuration in the cms.pm.cache:service=TreeCache Mbean:

		  <!--
           		Configuring the PortalCMSCacheLoader
           		
           		CacheLoader configuration for 1.4.0
           -->           
           <attribute name="CacheLoaderConfiguration">
               <config>                
                   <passivation>false</passivation>
                   <preload></preload>
                   <shared>false</shared>
                   <cacheloader>
                       <class>org.jboss.portal.cms.hibernate.state.PortalCMSCacheLoader</class>
                       <properties></properties>
                       <async>false</async>
                       <fetchPersistentState>false</fetchPersistentState>
                       <ignoreModifications>false</ignoreModifications>
                   </cacheloader>
               </config>
           </attribute>
		
	  

with the following configuration:

		  <!--
           		Configuring the PortalCMSCacheLoader
           		
           		CacheLoader configuratoon for 1.2.4SP2
           --> 
           <attribute name="CacheLoaderClass">org.jboss.portal.cms.hibernate.state.PortalCMSCacheLoader</attribute>       
           <attribute name="CacheLoaderConfig" replace="false"></attribute>
           <attribute name="CacheLoaderPassivation">false</attribute>
           <attribute name="CacheLoaderPreload"></attribute>
           <attribute name="CacheLoaderShared">false</attribute>           
           <attribute name="CacheLoaderFetchTransientState">false</attribute>
           <attribute name="CacheLoaderFetchPersistentState">false</attribute>
           <attribute name="CacheLoaderAsynchronous">false</attribute>        
	

Finally we can start both servers, open two shells and execute :

>cd $JBOSS_HOME/bin
>./run.sh -c ports-01

>cd $JBOSS_HOME/bin
>./run.sh -c ports-02

Web containers offer the capability to replicate sessions of web applications. In the context of a portal using portlets the use case is different. The portal itself is a web application that benefits of web application session replication. We have to make the distinction between local or remote portlets :

The servlet specification is very loose on the subject of replication and does not state anything about the replication of sessions during a dispatched request. JBoss Portal offers a portlet session replication mechanism that leverages the usage of the portal session instead which has several advantages

There are also some limitation such has you can only replicate portlet scoped attributes of a portlet session. It means that any attribute scoped using application scope are not replicated.

<web-app>
   ...
   <listener>
      <listener-class> org.jboss.portal.portlet.session.SessionListener </listener-class>
   </listener>
   ...
</web-app>

<portlet-app>
   ...
   <portlet>
      <portlet-name>YourPortlet</portlet-name>
      ...
      <session-config>
         <distributed>true</distributed>
      </session-config>
      ...
   </portlet>
   ...
</portlet-app>

public void processAction(ActionRequest req, ActionResponse resp) throws PortletException, IOException
{
   ...
   if ("addItem".equals(action))
   {
      PortletSession session = req.getPortletSession();
      ShoppingCart cart = (PortletSession)session.getAttribute("cart");
      cart.addItem(item);

      // Perform an explicit set in order to signal to the container that the object state has changed
      session.setAttribute("cart", cart);
   }
   ...
}