Recommended interim fixes when migrating profiles and data or upgrading to WebSphere Process Server V6.2.0 Fix Pack 1

Content

The fixes that are listed in this section are found either on Fix Central or on the WebSphere Process Server Support site.


Performance Interim fixes

JR31760
A memory leak can occur in the Service Component Architecture (SCA) code when targetSignificance is null. The references to configuration session objects that are used in the SCA are not released after use. In addition, each session creates an anonymous workspace in the wstemp directory. These conditions cause memory leaks and disk-shortage problems.
Download the fix for JR31760

JR33131
Out-of-memory problems are caused by the increasing number of anonymous subdirectories, potentially leading to a disk crash. The session object is not closed and is reacquiring the configuration values. This causes the increase in the number of subdirectories, which results in the out-of-memory errors.
Download the fix for JR33131

JR33299
High CPU use occurs when you migrate from WebSphere InterChange Server to WebSphere Process Server V6.2.0.1. The threaddump shows many threads waiting at:
at java.util.HashMap.get(HashMap.java:346)
at CxCommon.BusinessObject.<init>(BusinessObject.java:277)
at Collaboration.BusObj.<init>(BusObj.java:94)

This situation causes performance degradation. A migration fix bypasses this Java™ problem by using ConcurrentHashMap.
Download the fix for JR33299

JR33346
Asynchronous calls between WebSphere Enterprise Service Bus and WebSphere Process Server clusters can cause hung threads and transaction timeouts. The Service Component Architecture (SCA) gate is implemented as a performance alternative to thread synchronization in WebSphere Process Server V6.2.0.1.

However, the gate approach misses the case where a reentrant thread tries to acquire a lock. This action causes threads to hang and transaction timeouts when multiple events move through the system. The gate implementation has been modified to handle reentrant thread lock acquisition.
Download the fix for JR33346


Eclipse Modeling Framework interim fixes to address thread violations
The fixes in this section address the concurrency problems when using Eclipse Modeling Framework (EMF) APIs through various invocation paths. Even though the same NullPointerException occur, you can distinguish the exact error by looking at the stack trace.

JR33426
Because of a concurrency problem with EMF, when you use the business object APIs, a null value is sometimes returned, which results in incorrect output. A NullPointerException exception might occur during server startup:

Caused by: java.lang.NullPointerException                      
at org.eclipse.emf.ecore.sdo.impl.ETypeImpl.getInstanceClass(ETypeImpl.java:202)
at CxCommon.BusinessObject.processAttrs(BusinessObject.java:4410)      
at CxCommon.BusinessObject.getASI_info(BusinessObject.java:3921)        
at CxCommon.BusinessObject.getASI_info(BusinessObject.java:3853)
Download the fix for JR33426.

JR33492
The initialization of type Service Data Objects (SDO) metadata in a multithreaded environment causes a race condition, which results in a NullPointerException exception. You can recognize the failure pattern when an adapter list is at the top of the error stack:

Caused by: java.lang.NullPointerException                                
at org.eclipse.emf.ecore.util.EcoreUtil.getAdapter(EcoreUtil.java:148)  
at org.eclipse.emf.ecore.sdo.util.SDOUtil.adaptProperty(SDOUtil.java:557)
at org.eclipse.emf.ecore.sdo.util.SDOUtil.getContainmentProperty(SDOUtil.java:510)
Download the fix for JR33492.

JR32726
Multithreaded requests to a web service export immediately after server startup causes null pointer exceptions. The cause of the problem is that the types are not fully loaded because of concurrent access, which causes the thread violation. This fix resolved the NullPointerException exception that occurs intermittently at server startup.

Caused by: java.lang.NullPointerException
at org.eclipse.emf.ecore.util.BasicExtendedMetaData.getAllElements(BasicExtendedMetaData.java:866)
at org.eclipse.emf.ecore.util.BasicExtendedMetaData.getLocalElement(BasicExtendedMetaData.java:766)
at org.eclipse.emf.ecore.util.BasicExtendedMetaData.demandFeature(BasicExtendedMetaData.java:195)
Download the fix for JR32726.