eFix (APAR): PQ60828 Status: This is an efix for the WLM component For Release: WebSphere 4.0.1, 4.0.2, 4.0.3 For Edition: WebSphere AE, AEs For ContainerTypes: All For Operating System: all Supersedes eFixes: none CMVC defect: PQ60828 Date: 05/7/2002 Abstract: Fix of the problem where it looks as if WLM code is hanging while updating all running admin servers with new server group information. Description/symptom of problem: Admin server is taking unusually long time to come up. One of the following event or warning messages may also be observed in Admin console or Admin trace file: WWLM0014: Could not update Administrative Server information WLMBootstrapI E Comm failure pushing to admin server Administrator response: If the above problem occurs, the WebSphere installation may require efix PQ60828. To determine if the efix is needed, the Administrator must get a dump of the Java threads running in the AdminServer. One of the following methods may be used: When running in a UNIX environment: send a "kill -3" on the AdminServer process When running in Windows and AdminServer was started from a Windows command prompt, activate the window and press "Ctr-Break". This will dump the threads to the screen and a file. Search the javacore file that was created and see if any of the threads contain a line with "com.ibm.ws.wlm.bootstrap.WLMBootstrapImpl.initialize". If you find this line see if the thread contains similar information to the following thread dumps. If you do find this you are likely running into "long startup" problem where WebSphere is trying to update all the adminservers in the domain with new information. "P=3D326676:O=3D0:CT" (TID:0x9087e0, sys_thread_t:0x2374e0, = state:CW, native ID:0x678) prio=3D5 at java.lang.Object.wait(Native Method) at com.ibm.rmi.util.Condition.wait(Condition.java:47) at com.ibm.CORBA.iiop.IIOPConnection.send(IIOPConnection.java:1423) at = com.ibm.CORBA.iiop.ClientRequestImpl.invoke(ClientRequestImpl.java:508) at = com.ibm.CORBA.iiop.ClientRequestImpl.invoke(ClientRequestImpl.java:456) at com.ibm.CORBA.iiop.ClientDelegate.invoke(ClientDelegate.java:667) at com.ibm.CORBA.iiop.ClientDelegate.invoke(ClientDelegate.java:409) at org.omg.CORBA.portable.ObjectImpl._invoke(ObjectImpl.java:250) at = com.ibm.ws.wlm.server.config._WLMTemplate_Stub.push(_WLMTemplate_Stub.ja= va:156) at = com.ibm.ws.wlm.bootstrap.WLMBootstrapImpl.initializeServerGroupInfo(WLMB= ootstrapImpl.java:566) at = com.ibm.ws.wlm.bootstrap.WLMBootstrapImpl.initialize(WLMBootstrapImpl.ja= va:153) at = com.ibm.ejs.sm.server.AdminServer.initializeWLM(AdminServer.java:1246) at com.ibm.ws.runtime.Server.initializeRuntime0(Server.java:947) at = com.ibm.ejs.sm.server.ManagedServer.initializeRuntime0(ManagedServer.jav= a:408) at = com.ibm.ejs.sm.server.AdminServer.initializeRuntime0(AdminServer.java:11= 25) at com.ibm.ws.runtime.Server.initializeRuntime(Server.java:884) at com.ibm.ejs.sm.server.AdminServer.main(AdminServer.java:392) at java.lang.reflect.Method.invoke(Native Method) at com.ibm.ws.bootstrap.WSLauncher.main(WSLauncher.java:158) OR: "P=907019:O=0:CT" (TID:0xd487e0, sys_thread_t:0x774850, state:R, native ID:0x28a) prio=5 at java.net.PlainSocketImpl.socketConnect(Native Method) at java.net.PlainSocketImpl.doConnect(PlainSocketImpl.java:329) at java.net.PlainSocketImpl.connectToAddress(PlainSocketImpl.java:141) at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:128) at java.net.Socket.(Socket.java:285) at java.net.Socket.(Socket.java:112) at com.ibm.rmi.iiop.Connection.newSocket(Connection.java:79) at com.ibm.CORBA.iiop.ConnectionTable.get(ConnectionTable.java:549) at com.ibm.CORBA.iiop.ConnectionTable.get(ConnectionTable.java:413) at com.ibm.CORBA.iiop.GIOPImpl.createRequest(GIOPImpl.java:152) at com.ibm.CORBA.iiop.GIOPImpl.createRequest(GIOPImpl.java:133) at com.ibm.CORBA.iiop.ClientDelegate.createRequest(ClientDelegate.java:1080) at com.ibm.CORBA.iiop.ClientDelegate.request(ClientDelegate.java:1820) at org.omg.CORBA.portable.ObjectImpl._request(ObjectImpl.java:237) at com.ibm.ws.wlm.server.config._WLMTemplate_Stub.push(_WLMTemplate_Stub.java:152) at com.ibm.ws.wlm.bootstrap.WLMBootstrapImpl.initializeServerGroupInfo(WLMBootstrapImpl.java:566) at com.ibm.ws.wlm.bootstrap.WLMBootstrapImpl.initialize(WLMBootstrapImpl.java:153) at com.ibm.ejs.sm.server.AdminServer.initializeWLM(AdminServer.java:1246) at com.ibm.ws.runtime.Server.initializeRuntime0(Server.java:947) at com.ibm.ejs.sm.server.ManagedServer.initializeRuntime0(ManagedServer.java:408) at com.ibm.ejs.sm.server.AdminServer.initializeRuntime0(AdminServer.java:1125) at com.ibm.ws.runtime.Server.initializeRuntime(Server.java:884) at com.ibm.ejs.sm.server.AdminServer.main(AdminServer.java:392) at java.lang.reflect.Method.invoke(Native Method) at com.ibm.ws.bootstrap.WSLauncher.main(WSLauncher.java:158). If security is enabled, there will also be a symptom of an initialization problem during Admin server startup time. If security is enabled, the security e-fix PQ61779 will also need to be applied. Directions to apply efix: 1) Create temporary "efix" directory to store the zip/tar file: AIX: /tmp/WebSphere/efix Solaris/Linux: /tmp/WebSphere/efix Windows: c:\temp\WebSphere\efix 2) Copy zip/tar file to the directory 3) Unzip/untar the file 4) Shutdown WebSphere 5) Run the jar file with the following command answering questions/prompts as they appear: java -jar 6) Restart WebSphere 7) The temp directory may be removed but the zip/tar 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. Trouble shooting -------------------------------------------------------------------------------------- o If an efix complains about the container type and you are sure it should match, contact WebSphere L2 Support for assistance with the -SkipContainerCheck option to the efix jar. o If the efix complains about the version of XML parser, move the file $WASROOT/jre/lib/ext/xerces.jar to a temporary location (such as c:\temp), load the efix and move the file back to it's original location. Additional Information: ------------------------------------------------------------------ none