Name: PK37495
=============
 
Summary:
   Better cluster awareness for reload of public pages
 
Problem Description:
   After an XML Access import, the public pages will only refresh on the server the file was imported to. In a cluster environment this means that the updates made to public pages will show on other nodes only when the public pages reload interval has expired.
   
   This PK introduces a new cache and configuration file that must be properly configured before the portal
   is started.
   
   Cache:
   In Portal V5.1.0.4, the CacheManagerService.properties file needs to be extended with the following
   lines:
   	# Model Caches
   	####################################################################
   
   	cacheinstance.com.ibm.wps.model.factory.public.pages.update.shared=false
   	cacheinstance.com.ibm.wps.model.factory.public.pages.update.enabled=true
   	# size should be greater or equal to "number of markups * number of virtual portals"
   	cacheinstance.com.ibm.wps.model.factory.public.pages.update.size=100
   	cacheinstance.com.ibm.wps.model.factory.public.pages.update.lifetime=-1
   	cacheinstance.com.ibm.wps.model.factory.public.pages.update.transactionaware=false
   
   In Portal V6, these values need to be set accordingly using the admin console (see InfoCenter).
   It is possible to set this cache to "shared"; this will cause all servers of a cluster to reload the public pages at about the same time. When left to "non-shared", updates made to the public pages via XML Access will only show immediately on the node the file was imported to. To manually refresh public pages on other servers of a cluster, the following XML Access script can be sent to those servers:
   	<?xml version="1.0" encoding="UTF-8"?>
   	<request xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
        	    build="wp5103_025" type="update" version="5.1.0.3"
   	         skip-cache-refresh="false"
   	         xsi:noNamespaceSchemaLocation="PortalConfig_1.3.1.xsd">
   	    <portal action="locate"/>
   	</request>
   
   Configuration:
   In Portal V5.1.0.4, a new file called ModelFactoryService.properties needs to be located at <wps>/shared/app/config/services (i.e. at the same location where CacheManagerService.properties resides). The
   file should have the following content:
   	# a list of public pages models that are to be initiated at portal startup time
   	#
   	# format: init.public.pages.<markup-name> = (true|false)
   	#
   	# if no entry is specified, the value for that markup defaults to "false"
   
   	init.public.pages.html = false
   	init.public.pages.chtml = false
   	init.public.pages.wml = false
   
   In Portal V6, these values need to be set accordingly using the admin console (see InfoCenter).
   It is possible to set the values for the different markups to "true". This will cause portal to load the public pages at startup rather than at first access (by users) - this can be beneficial for portal response times when portal is immediately put under load and is not "ramped" up.
   
 
Problem Solution:
   The code controlling the reloads of public pages was changed to be cluster aware, i.e. it is possible to instruct all servers of the cluster to reload the public pages. Also, to avoid race conditions for loading public pages at startup, a "preload" option was introduced.
   
 
Failing Module(s):
   Engine: Tags & Commands
 
Affected Users:
   All users
 
Version Information:
    Portal Version(s): 5.1.0.4
     Pre-Requisite(s): PK37413 
      Co-Requisite(s): ---
 
Platform Specific:
   This fix applies to all platforms.
 
Installation:
   NOTE:  YOU MUST FIRST DOWNLOAD THE UPDATE INSTALLER TOOL IN ORDER TO INSTALL A FIX.
          The Portal Update Installer can be downloaded from the following link:
          http://www.ibm.com/software/genservers/portal/support
 
   1. Create temporary "fix" directory to store the jar file.
   2. Copy jar file to this directory.
   3. Shutdown WebSphere Portal.
   4. Follow the fix installation instructions that are packaged with
      the Portal Update Installer on how to install the fix.
   5. Restart WebSphere Portal.
   6. The temporary directory may be removed.
 
Un-Installation:
   NOTE:  FIXES MUST BE REMOVED IN THE ORDER THEY WERE APPLIED.  DO NOT REMOVE
          A FIX UNLESS ALL FIXES APPLIED AFTER IT HAVE FIRST BEEN REMOVED.
          YOU MAY REAPPLY ANY REMOVED FIX.
 
   1. Shutdown WebSphere Portal.
   2. Follow the instructions that are packaged with the
      Portal Update Installer on how to uninstall the fix.
   3. Restart WebSphere Portal.