Install > Installing maintenance > WCS > Installing WCS interim fixes
Use the roll out update process for installing interim fixes
Overview
Roll out update is a means to achieve high availability when applying interim fixes to the WCS application which is deployed to a clustered environment. Not all nodes in the cluster need to be shut down during the process. The deployment manager chooses one node and stops the server only on that specific node. After synchronizing the updates for the node, the server is started again. The process is repeated for each node in the cluster.
To use roll out update...
- The interim fixes must be marked with...
This fix is roll out update enabled.
- WCS Update Installer version 7 or higher is installed.
- The WCS application is federated and clustered with two or nodes.
- Test the interim fixes on a non-production environment first.
- Verify these actions are not scheduled at the same time the roll out update is run:
- Store Publish
- Stage Propagation
- File/attachment upload
- Installation of other product fixes
- Update Logo
- PCI Encryption
- Any explicit EAR update such as the deployment of customizations through the WAS
- The WCS application is active when the interim fixes are applied.
The roll out update runs for a longer time when compared to the regular process of applying fixes. The nodes in the cluster are being updated sequentially rather than in parallel. These means that some nodes in the cluster have updated code while other nodes do not. Ensure this condition is feasible for the environment especially if you are using customized code.
- If a lower failover time is required OR if the following message is posted in the browser window:
Servlet has become temporarily unavailable for service
...edit plugin-cfg.xml file and decrease the failover time:
ServerIOTimeout Reduce to 30 ConnectTimeout Reduce to 15
Also consider modifying the following properties:
WebContainer custom property com.ibm.ws.webcontainer.ServletDestroyWaitTime JVM Custom Property com.ibm.ejs.sm.server.quiesceTimeout JVM Custom Property com.ibm.ejs.sm.server.quiesceInactiveRequestTime
- If you see application exceptions in the server logs during the roll out update process, the default 60 second wait time might not be enough. See the PK46763 readme file for instructions on increasing the wait time.
- Do not use the roll out update process to:
- Apply WCS fix packs
- Apply WAS fix packs
- Apply WAS interim fixes
- Uninstall any WCS or WAS interim fixes
Apply interim fixes to WCS product using WCS update installer
To enable the roll out update to apply interim fixes...
- Create the earUpdateControl.properties file in one or both locations depending on the type of instance you are updating:
- WCS instance:
- WC_INSTALL/instances/instance/properties
- WC_USER/instances/instance/properties
- WCS payment instance:
- WC_INSTALL/payments/pay_instance/properties
- WC_USER/payments/pay_instance/properties
- Edit each earUpdateControl.properties file you created. Add the following lines:
earupdate.disablesync = true earupdate.do.rolloutupdate= true earupdate.restoresync= true
- Save and exit the file.
- Run the WCS Update Installer and apply the interim fixes to the WCS product
- Run the WCS Update Installer and apply the interim fixes to the WCS instance or payments instance. See the example section for roll out update information.
- After the installation process has completed and the WebSphere Commerce update installer returns a success message, the roll out update is complete. Continue to apply any other interim fixes.
If you see an error during the update, increase the timeout value...
com.ibm.websphere.management.application.updateapponcluster.timeoutIncrease in 5 minute increments, do not use a value greater than 60 minutes.
[8/25/09 16:16:31:709 GMT+08:00] 00000017 TreeBuilder W ODCF0002E: Exception: java.lang.reflect.InvocationTargetException .
Caused by: org.eclipse.jst.j2ee.commonarchivecore.internal.exception.NestedJarException:
IWAE0008E An error occurred reading InitializationServlet.war from /WAS70/profiles/myprof/config/cells/cellname/applications/WC_demo.ear/deployments/WC_demo.
Caused by: java.io.FileNotFoundException: /WAS70/profiles/AppSrv01/installedApps/WC_demo_cell/WC_demo.ear/InitializationServlet.war (A file or directory in the path name does not exist.)
Example
Indications that the roll out update is deploying the interim fix:
- Check the log...
WC_INSTALL/logs/update/actions/install/exportEar_WC_instance.logSince the WCS application should be running during the process of fix installation, if the log contains messages similar to the following messages:
[wsadmin] WC_demo on node wcs204Node01 with process member01 stopped
[wsadmin] WC_demo on node WC_<instance>_node with process server1 stopped...ensure that the steps to set up roll out update are completed.
- Check the log...
WC_INSTALL/logs/update/actions/install/deployEar_WC_instance.logThe log file should contain messages related to the tasks...
deployEarWithSecurity
deployEarWithoutSecurityThe messages are similar to the following messages:
[wsadmin] *** Automatic node synchronization disabled
[wsadmin] *** Update of WC_instance from /tmp/wcupdate/WC_instance.ear complete
[wsadmin] *** Configuration saved
[wsadmin] *** WC_instance is clustered, rollout update used
[wsadmin] *** Rollout update invoked
[wsadmin] *** Automatic node synchronization restored
- Monitor the roll out update process by reviewing the node agent SystemOut.log files. If messages, similar to the ones listed, are found in the node agent's SystemOut.log, then roll out update has completed on that particular node. Eventually, all nodes should show indications of roll out update completion.
0000001f NodeSync A ADMS0019I: Automatic synchronization mode is disabled.
0000001a RmmPtpGroup W DCSV1111W: DCS Stack DefaultCoreGroup at Member /cell_name\
node_name\nodeagent: Suspected another member because the outgoing connection from the other member was closed. Suspected members is cell_name\node_name\server_name. DCS logical channel is View|Ptp.
ADMS0003I: The configuration synchronization completed successfully. Commerce updating file permission on application WC_instance Script file is: /tmp/WC_instance2008.11.10.14.14.00.000321.sh
ADMN1001I: An attempt is made to launch server_name on node node_name.
DCSV1032I: DCS Stack DefaultCoreGroup at Member cell_name\node_name\nodeagent: Connected a defined member cell_name\node_name\server_name. Commerce has finished updating file permission on application WC_instance
DCSV2004I: DCS Stack DefaultCoreGroup at Member cell_name\node_name\nodeagent: The synchronization procedure completed successfully. The View Identifier is (130:0.cell_name\dmgr_hostname\dmgr). The internal details are [0 0 0 0].
HMGR0228I: The Coordinator is not an Active Coordinator for core group DefaultCoreGroup.
HMGR0218I: A new core group view has been installed. The core group is DefaultCoreGroup. The view identifier is (131:0.cell_name\dmgr_hostname\dmgr). The number of members in the new view is 5.
DCSV8050I: DCS Stack DefaultCoreGroup at Member cell_name\node_name\nodeagent: New view installed, identifier (131:0.cell_name\dmgr_hostname\dmgr), view size is 5 (AV=5, CD=5, CN=5, DF=7)
DCSV1033I: DCS Stack DefaultCoreGroup at Member cell_name\node_name\nodeagent: Confirmed all new view members in view identifier (131:0.cell_name\dmgr_hostname\dmgr). View channel type is View|Ptp.
ADML0000I: The server initialization is complete. The process ID is: 51034
ADMD0023I: The system discovered process (name: <server_name>, type: ManagedProcess, pid: 51034)
ADMS0018I: The automatic synchronization mode is enabled.
What to do next
When you have completed applying all the identified fixes, remove the earUpdateControl.properties file. Removing this file avoids the problem of using the roll out update for future interim fixes that might not be enabled for the roll out update process.