Fix (APAR):  JR32360

Status:  Fix

Release:  6.0.2.4

Operating System:  AIX,HP-UX,i5/OS,Linux,Solaris,Windows,z/OS

Supersedes Fixes:  

CMVC Defect:  JR32360

Byte size of APAR:  10476

Date: 2009-04-28

Abstract:  Loading of Business Object classes on the server forces unnecessary loading of other components.

Description/symptom of problem:  
JR32360 resolves the following problem:

ERROR DESCRIPTION:                                              
Customer reported slow initialization of WPS in the Control     
Region of zOS. The problem was traced to Relationship XSDs      
trying to load up the Business Objects.                         
                                                                
On zOS.  We have a Control_Region(1) that dispatches work       
requests to application Servant_Regions(*).   This is part of   
the WebSphere zOS architecture which provides significant       
scalability. A WebSphere server on zOS is already clustered     
consisting of multiple JVM's that will process Application      
work.  On zOS, we utilize  server clustering for scalability    
and the WebSphere clustering for availability.                  
                                                                
MBean requests are being initiated in a Servant. They get       
dispatched to the Control_Region and scheduled to run in a      
servant (potentially different than the originating servant).   
This processing requires serialization/deserialization in the   
Control_Region.  Any Objects passed on the MBean request must   
be accessible on the Control_Region classpath.                  
Without ArtifactLoader, dynamic EMF classes cannot be found.    
                                                                
RelationshipManagerMBean is using BusinessObjects(BO) as payload
to their MBean requests. These Business Objects are not on the  
ClassPath of the ControlRegion.  We agreed in WPS601 to allow   
the Classpath to be extended in the Control_Region but only     
with static EMF packages.  We do not want any extraneous        
Components running in the Control_Region, particularly when     
most people don't know that it even exists. We try to           
keep the footprint of the CR as small as possible, and we do not
want any application code running in this JVM. If this JVM      
fails, then the Server is down.                                 
                                                                
The com.ibm.relationship.startup.WASBootstrap component is      
currently starting in the Control_Region for the sole purpose of
registering these static EMF classes for Relationships. It      
appears that the BOUtility is causing the SCAContainer to be    
created within the Control_Region. This is causing a            
significant amount of processing in the Control_Region and      
NodeAgent.                                                      

LOCAL FIX:                                                      
n/a                                                             

PROBLEM SUMMARY

USERS AFFECTED:
 WebSphere Process Server or
WebSphere Enterprise Service Bus
v6.0.2.x users with
a cluster setup on zOS.

PROBLEM DESCRIPTION:
Loading of Business Object classes on
the server forces unnecessary loading
of other components.

RECOMMENDATION:
None

A Business Object utility was causing the Service Component
Architecture to load into memory, which uses up unnecessary
processor time and memory on "control region" of servers in zOS
cluster setup.

PROBLEM CONCLUSION:                                             
Applying this interim fix will resolve the issue.               


Directions to apply fix:  
Download and follow Update Installer installation instructions.  The Update Installer can be downloaded from the following link:
http://www.ibm.com/support/docview.wss?rs=180&uid=swg21205991

1) Copy the pak file to the directory maintenance in the UpdateInstaller directory

2) Shutdown WebSphere Process Server. It is important that you perform a controlled and complete shutdown of the server to ensure that all transactions have completed, before installing the fix.

3) Run the UpdateInstaller and follow the prompts.

4) Restart WebSphere Process Server.

Directions to remove fix:  
NOTE:  FIXES MUST BE REMOVED IN THE REVERSE ORDER IN WHICH THEY WERE APPLIED.  DO NOT REMOVE A FIX UNLESS  ALL FIXES APPLIED AFTER IT HAVE FIRST BEEN REMOVED.  YOU MAY REAPPLY ANY REMOVED FIX.

Example:  If your system has fix1, fix2, and fix3 applied in that order and fix2 is to be removed, fix3 must be removed first, then fix2 may be removed

1) Shutdown WebSphere Process Server. It is important that you perform a controlled and complete shutdown of the server to ensure that all transactions have completed, before installing the fix.

2) Follow the Fix instructions that are packaged with the Fix Installer on how to uninstall and reinstall the Fix.

3) Restart WebSphere Process Server.

Directions to re-apply fix:  
1) Shutdown WebSphere. It is important that you perform a controlled and complete shutdown of the server to ensure that all transactions have completed, before installing the fix.

2) Run the UpdateInstaller and follow the instructions. The Update Installer can be downloaded from the following link:
http://www.ibm.com/support/docview.wss?rs=180&uid=swg21205991

3) Restart WebSphere Process Server.

Additional Information: