Clients which use the Websphere installation directory must be stopped for proper application of this eFix. Release: WebSphere 4.0.2 Operating System: All Supersedes eFixes: PQ61779, PQ62538, PQ62684, PQ63116, PQ63574, WAS_Security_09-13-2002_4.0.4-4.0.3_client_cumulative_eFix and WAS_Security_10-07-2002_4.0.4-4.0.3_client_cumulative_eFix and WAS_Security_10-31-2002_4.0.4-4.0.3_client_cumulative_eFix as well as any eFixes for APARs listed below. CMVC defect: See APAR list below Byte size of APAR: 1,381,694 Date: 11/24/2002 Description/symptom of problem: See APAR list below. Directions to apply efix: 1) Create temporary "efix" directory to store the jar file: AIX: /tmp/WebSphere/efix Solaris/Linux: /tmp/WebSphere/efix Windows: c:\temp\WebSphere\efix 2) Copy jar file to the directory 3) Shutdown WebSphere 4) Run the jar file with the following command answering questions/prompts as they appear: java -jar 5) Restart WebSphere 6) The temp directory may be removed but the jar file should be saved. Do not remove any files created and stored in the /WebSphere/AppServer/efix/ directories. These files are required if an efix is to be removed. Directions to remove an efix: NOTE: EFIXES MUST BE REMOVED IN THE ORDER THEY WERE APPLIED. DO NOT REMOVE AN EFIX UNLESS ALL EFIXES APPLIED AFTER IT HAVE FIRST BEEN REMOVED. YOU MAY REAPPLY ANY REMOVED EFIX. Example: If your system has efix1, efix2, and efix3 applied in that order and efix2 is to be removed, efix3 must be removed first, efix2 removed, and efix3 re-applied. 1) Change directory to the efix location (/WebSphere/AppServer/efix/). 2) Shutdown WebSphere 3) Run the backup jar file with the following command: java -jar 4) Restart WebSphere Directions to re-apply an efix: Follow the instructions for applying an efix. If the backup files still exist (from the previous efix application), you will be prompted to overwrite. Answer "yes" at the overwrite prompts. Additional Information: ------------------------------------------------------------------ The following properties must be set for PQ56218 to be effective: In the admin.config file: com.ibm.CORBA.ListenerPort=2000 com.ibm.CORBA.SSLPort=2001 com.ibm.CORBA.LSDPort=9000 com.ibm.CORBA.LSDSSLPort=9001 In each of the Application servers system properties: com.ibm.CORBA.ListenerPort=3000 com.ibm.CORBA.SSLPort=3001 Note, each port number must be unique and must not be in use by any other service on the system. Included APARS: APAR: PQ56218 Version: 400 Abstract: PMI DOES NOT RECOVER WHEN WEBSPHERE APP SERVER IS RESTARTED WHEN SECURITY ENABLED Error Description: ** Brief Description: Customer has a java PMI client (Performance Monitoring Infrastructure)programming interface provided by IBM. -- It logs into WAS fine the first time but when you stop and restart WAS with security on it does not log back in. Getting error Cannot create PmiService bean obj; nested exception is: java.rmi.RemoteException: CORBA INTERNAL 0 No Local Fix: none Logically Dependent Apars: Users Affected: All WebSphere Application Server users which have enabled security. Problem Description: Java clients fail to log into WebSphere Application Server after the server is restarted with security enabled. Recommendation: Problem Summary: After the Java client logged into the WebSphere Application Server, if the server restarts for any reason, then the Java Client cannot login again with security enabled. The client will get the java.rmi.RemoteException: CORBA INTERNAL 0 Problem Conclusion: When the client receives a request reject message, the client now checks the credential associated with the request. If the credential is a dummy credential, then the client tries to re-establish the secure association with the server again. Test Comments: Circumvention: Temporary Fix: PQ56218_eFix_AEServer.jar Comments: APAR: PQ58764 Version: 400 Abstract: CORBA EXCEPTION ERROR Error Description: The customer stated when java client his the application server he is getting the following error into the client stdout file: CORBA exception errors... failed mutual authentication handshake... session does not exist in the session table. He also noticed jsa150e-unable to find session in the session table errors. Def ect 120428 Local Fix: No fix or workaround available yet. Logically Dependent Apars: Users Affected: All WebSphere Application Server users which have enabled security. Problem Description: CORBA exception errors with failed mutual authentication message Recommendation: Problem Summary: Client gets CORBA exception errors, failed mutual authentication handshake after 45 minutes of attempting to complete the request. The following CORBA exception occurs: "org.omg.CORBA.NO_PERMISSION: Failed mutual authentication handshake. Session does not exist in the session table." Problem Conclusion: The server now passes back the security context along with the exception, so the client can react accordingly. Test Comments: Circumvention: Temporary Fix: PQ58764_401_test.jar Comments: APAR: PQ55948 Version: 350 Abstract: OUTOFMEMORY (MEMORY LEAK) OCCURS WHEN SECURITY IS ENABLED AND APPLICATION SPAWNS A ASYNCHRONOUS THREAD WHICH MAKES AN ORB CALL Error Description: Environment: WebSphere Application Server (WAS) 3.5.3 Advanced Edition . Description: Customer has a servlet which spawns a thread which in turn makes a call to MQSeries. In this scenario, when WAS security is enabled, a memory leak occurs which eventually results in OutOfMemory as objects instantiated by the servlet stay around because security references to the objects don't go away. Local Fix: None Logically Dependent Apars: Users Affected: All WebSphere Application Server users which have deployed servlets which are EJB clients and instantiate new threads and WebSphere security is enabled. Problem Description: Security associates thread specific data with the hashtables which prevent the threads from being garbage collected. Recommendation: Problem Summary: Security associates thread specific data with the hashtables using the thread object as a key. Since there is a reference to the thread object stored in a hashtable, the thread object will not be garbage collected even if it has gone out of context in the servlet. This issue can be exacerbated by subclassing the thread in which the subclassed thread has references to large data objects. Problem Conclusion: Logic was added to the hashtables to periodically remove all references to threads which were no longer executing. The logic is activated if N new threads are added to the hashtable since the last time the removal logic has run. N is a tuneable value which defaults to 100 and is set by the "com.ibm.CORBA.threadStateCleanupDelta" property. Test Comments: Circumvention: Don't instantiate new threads within a servlet or manage a thread pool to limit the number of new threads instantiated. Also, clear all instance data before the thread exits. Temporary Fix: ZE FIX ERROR PQ65082 02/09/10 An efix fix is available for 3.5.3. Comments: