PQ48859: THIS APAR ADDRESSES DEFECTS IN WEBSPHERE APPLICATION SERVER V4.0 FOR Z/OS AND OS/390. | |||||||||||||||||||||||||||||||||||||||||||||||||||||
![]() |
|||||||||||||||||||||||||||||||||||||||||||||||||||||
![]() APAR status Closed as program error. Error description This APAR addresses defects in WebSphere Application Server V4.0 for z/OS and OS/390.Local fix Problem summary **************************************************************** * USERS AFFECTED: All users of WebSphere Application Server * * V4.0 for z/OS and OS/390. * **************************************************************** * PROBLEM DESCRIPTION: APAR PQ48859 addresses various problems * * in WebSphere Application Server V4.0 * * for z/OS and OS/390. * **************************************************************** * RECOMMENDATION: * **************************************************************** APAR PQ48859 addresses the following problems in WebSphere Application Server V4.0 for z/OS and OS/390: Message ICH408I is displayed on console, and the webserver fails to service the request because the CB.BIND.* check from webserver to a server region failed. If the local identity check for CB.BIND control by the webserver client fails, the request fails. This behavior is inconsistent with the behavior of remote processing. A remote CB.BIND.* check failure does not fail the request. It instead checks each request to verify the identity of the client for the CB.* check. The CLASSPATH entries "xerces.jar" and "ibmjndi.jar" should be removed from the initial environment file. "ibmjndi.jar" is no longer needed at all. In addition, the informational message that shows up in the Systems Management server region (if exception-level trace was turned on) if "ibmjndi.jar" could not be found within the initial or user-specified CLASSPATH should be removed. Also, "xerces.jar" is added automatically to the CLASSPATH while the environment file is written, so this entry is no longer required within the initial environment file. If the message "BBON046E Unable to export server ..." appears. The Administration Message log contains also a message BBON0900E Message 1126 not found in com.ibm.cb390sm.SMMsgDef" The user response for BBOU0394W is misleading and needs to be more specific about the necessary steps for changing the daemon IP name. Message text is missing text for Scripting API error message BBON1138E. If a REXX script is run that specifies an invalid XML file the message BBON3011 - Getting xml parser reference failed is returned. The Messages and Diagnosis documentation does not suggest any specific action other then to contact IBM. The customers REXX script for the SM Scripting API call 'createserver' needs to have a parameter 'procname' specified. Since the default XML file used for this action has no value assigned to the attribute 'procname' it has to be done by the script. According to the Administration Application this behavior is not correct. The script doesn't need to specify parameter 'procname'. If an application server is multi-threaded there is a chance that it will hang during the Naming Registration of the applications. A hang can also occur when the server is under a heavy load. Usually the server that hangs is a new one starting The hang condition results because there is a problem in the class loader that causes a loop back condition on multiple threads. This loop back causes two different locks to be obtained which results in a dead lock in the server and no further work can be processed. Message BBOU0709E is written to the server's log when it should not be. The message BBOU0709E, which indicates that a user is calling a method and is not in a defined ROLE, is issued even when the user is in the role. If EJBs and Servlet engine are running in the same Application Server, you may get the following errors at the Web Browser or in the Application Server: java.lang.LinkageError or java.lang.StackOverflowError. The following is additional information you'll see in the Application Server Region for java.lang.LinkageError Error invoking a method on an EJB instance : java.rmi.ServerError: Error occurred in server thread; nested exception is: java.lang.LinkageError: Class <your class name> violates loader constraints. The stack trace in the server will look similar java.lang.LinkageError: Class <your class name> at java.lang.ClassLoader.defineClass0(Native Method) at java.lang.ClassLoader.defineClass(ClassLoader.java:496) at java.security.SecureClassLoader.defineClass (SecureClassLoader.java:117) at com.ibm.ws.classloader.CompoundClassLoader.findClass (CompoundClassLoader.java at com.ibm.ws.classloader.CompoundClassLoader.loadClass (CompoundClassLoader.java at java.lang.ClassLoader.loadClass(ClassLoader.java:257) at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:212) at sun.rmi.server.LoaderHandler.loadClass(LoaderHandler.java:316 at sun.rmi.server.LoaderHandler.loadClass(LoaderHandler.java:88) at java.rmi.server.RMIClassLoader.loadClass (RMIClassLoader.java:66) at com.ibm.rmi.util.JDKBridge.loadClassM(JDKBridge.java:249) at com.ibm.rmi.util.JDKBridge.loadClass(JDKBridge.java:95) at com.ibm.rmi.javax.rmi.CORBA.Util.loadClass(Util.java:372) at javax.rmi.CORBA.Util.loadClass(Util.java:236) at com.ibm.rmi.util.Utility.loadClassOfType(Utility.java:432) at com.ibm.rmi.util.RepositoryId.checkClassCache (RepositoryId.java:535) at com.ibm.rmi.util.RepositoryId.getClassFromType (RepositoryId.java:492) at com.ibm.rmi.iiop.CDRInputStream.read_value (CDRInputStream.java:1114) at com.ibm.rmi.javax.rmi.CORBA.Util.copyObject(Util.java:630) at com.ibm.ws390.rmi.corba.Util.copyObject(Util.java:300) at javax.rmi.CORBA.Util.copyObject(Util.java:316) at <your ejb classname>_BaseStub.<method name> (<your ejb classname>.java:<line>) at <your ejb classname>_Stub.sellStockFor (<your ejb classname>.java:<line>) at <your servlet name>.<method name> (<your servlet name>.java:<line>) at <your servlet name>.<method name> (<your servlet name>.java:<line>) at javax.servlet.http.HttpServlet.service(HttpServlet.java:740) at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) at <your servlet name>.<method name> (<your servlet name>.java:<line>) at com.ibm.servlet.engine.webapp.StrictServletInstance.doService (ServletManager The following is additional information you'll see in the Application Server Region for java.lang.StackOverflowError java.lang.StackOverflowError at org.omg.CORBA.portable.ObjectImpl._is_local (ObjectImpl.java:205) at com.ibm.rmi.javax.rmi.CORBA.Util.isLocal(Util.java:387) at javax.rmi.CORBA.Util.isLocal(Util.java:255) at <classname>_BaseStub.create(<classname>.java:<line>) at <classname>_Stub.create(<classname>.java:<line>) at <classname>_BaseStub.create(<classname>.java:<line>) at <classname>_Stub.create(<classname>.java:<line>) at <classname>_BaseStub.create(<classname>.java:<line>) at <classname>_Stub.create(<classname>.java:<line>) at <classname>_BaseStub.create(<classname>.java:<line>) at <classname>_Stub.create(<classname>.java:<line>) These problems were caused by loading the same class with different classloaders. Server Regions are not getting Java Dumps from the JVM. Also, WebServer threads are terminated by WebSphere client code when a SIGPIPE signal is raised. WebSphere's Signal handler, RasSignalHandler2 (bborexit.cpp), is not driving the JVM's Signal handler for SIGTERM Signals. The JVM's Signal Handler needs to be driven in order for a JAVADUMP to be taken. Also, WebSphere's Signal handler is defined to receive control for SIGPIPE Signals. In the client environment, such as WebServer, this circumvents the expected behavior for the SIGPIPE as related to errno's received from a socket "send()". In this case, WebServer communication code expected to receive an errno of EPIPE (errno.h) to indicate that the Socket was in a "broken pipe" situation. Instead it never got control. WebSphere's Signal handler got control and determined the Signal was not meant for WebSphere code and took the "Default" action for a SIGPIPE--which is to terminate the thread. Over time, the WebServer lost most/all of its communication threads and useful work ceased. Also, ABENDS0C1, ABEND0C1, ABEND 0C1 could result from the RasSignalHandler2 routine when attempting to invoke a previously defined Signal Handler (like the JVM's Signal Handler).Problem conclusion The local CB.BIND.* check failure would classify the session as a checksess session and each request verifies the identity of the client for the CB.* check. The CLASSPATH entries "xerces.jar" and "ibmjndi.jar" have been removed from the initial environment file. "ibmjndi.jar" is no longer needed at all. Therefore it has been removed from the initial environment file. In addition, the informational message that shows up in the Systems Management server region (if exception-level trace was turned on) if "ibmjndi.jar" could not be found within the initial or user-specified CLASSPATH has been removed. Also, "xerces.jar" is added automatically to the CLASSPATH while the environment file is written, so this entry has been removed from the initial environment file. If the CLASSPATH for existing servers contains these jar files, it will not cause any problems. com.ibm.cb390sm.SMMsgDef has been modified to contain message BBON1126E. The user response for message BBOU0394W (if the Daemon IP name needs to be changed) has been updated to be the following: 1. Prepare your system for a cold start. This step will preserve the existing configuration and can be invoked through the WebSphere for z/OS Administration application. 2. Drop and recreate the WebSphere for z/OS System Management and LDAP databases. 3. Rerun the bootstrap procedure. The instructions for steps 2 and 3 are described in detail in Chapter 3 of the Installation and Customization guide: "Installing and customizing your first run time." The text for error message BBON1138E was added to the SM Scripting API message file. The client now returns the message BBON3011 saying 'Xml input file is not valid'. Also, an additional message is printed out on the screen giving an appropriate hint that helps to isolate the error. SM Scripting API call 'cretaeserver' has been modified to not require the specification of parameter 'procname'. Support has been modified in the class loader to prevent the loop back condition, thus preventing the reported hang condition from occuring. Module bbossejb.cpp has been modified correctly issue message BBOU0709E. Support has modified the classloading process so that a class will only be loaded by one classloader. Code has been modified in WebSphere's Signal Handler to invoke the JVM's Signal Handler in a Server Region. This will allow the JVM to gather a JAVADUMP when a SIGTERM is raised. Code has also been modified in WebSphere's Signal Handler, RasSignalHandler2 (bborexit.cpp), to "Ignore" SIGPIPE Signals in WebSphere address spaces (this includes the client space, like WebServer). Code has been added to the RasSignalHandler2 (bborexit.cpp) to properly process the sigaction structure (signal.h) when determining if and how to invoke a previously defined Signal Handler. APAR PQ48859 is associated with SERVICE LEVEL W400012 of WebSphere Application Server V4.0 for z/OS and OS/390.Temporary fix Comments
APAR is sysrouted FROM one or more of the following: APAR is sysrouted TO one or more of the following: UQ54362 Modules/Macros
|
Document Information |
Product categories: Software > Application Servers >
Distributed Application & Web Servers > WebSphere Application
Server for z/OS
Operating system(s):
Software version: 400
Software edition:
Reference #: PQ48859
IBM Group: Software Group
Modified date: Jun 5, 2001
(C) Copyright IBM Corporation 2000, 2006. All Rights Reserved.