PQ59714: IN WAS/390 V401, WHEN MANY EJBS ARE DEPLOYED, SR INITIALIZATION TAKES VERY LONG TIME TO COMPLETE CLASSLOADING | |||||||||||||||||||||||||||||||||||||||||
![]() |
|||||||||||||||||||||||||||||||||||||||||
![]() APAR status Closed as program error. Error description After migrating to WAS/390 V4.0.1, Server Region initialization becomes to take very long time. This problem is typically seen when large number of EJB Jars and/or EARs are deployed. In our case, SR initialization took 17 seconds in WAS/390 V4.0, which now takes more than 20 minutes (we have 380 EJBs deployed). *=all=enabled trace shows many activities being done in classes in classloader package (ClassGraph, ClassLoaderGroup, etc.). Took a dump and looked at the top of the stack. The last method being executed was "detectLoop".Local fix Problem summary **************************************************************** * USERS AFFECTED: All users of WebSphere Application Server * * V4.0.1 for z/OS and OS/390 * **************************************************************** * PROBLEM DESCRIPTION: Initialization of WebSphere V4.0.1 * * Server is slow when applications * * contain large numbers of modules (EJBs, * * WARs, and Utility jars). * **************************************************************** * RECOMMENDATION: * **************************************************************** WebSphere server initialization time increased from WebSphere V4.0 to WebSphere V4.0.1.Problem conclusion When WebSphere 4.0.1 was released, the classloader methodology was changed from that on WebSphere V4.0. On WebSphere V4.0, there was one classloader for all EJBs and Utilities, and one classloader for all WARs. On WebSphere V4.0.1, there is potentially one classloader for every EJB, WAR, and Utility jar in the server. The default determination of how many classloaders are required was changed to take advantage of the different visibility modes available in WebSphere V4.0.1. These changes reduce the initialization time to a value that is closer to WebSphere V4.0 initialization time. The following publication was revised as a result of APAR PQ59714: ________________________________________________________________ WebSphere Application Server V4.0.1 for z/OS and OS/390 Messages and Diagnosis GA22-7837-02 ________________________________________________________________ This APAR requires changes to documentation. NOTE: Periodically, we refresh the documentation on our Web site, so the changes might have been made before you read this text. To access the latest on-line documentation, go to the product library page at: http://www.ibm.com/software/webservers/appserv/ ________________________________________________________________ Chapter 13, pg. 231 (new message) BBOJ0033I AN ERROR OCCURRED LOADING INFORMATION FOR APPLICATION ID {0} IN WEBSPHERE z/OS SERVER {1} Explanation: During WebSphere z/OS server initialization all of the installed applications are checked for the contained modules (EJBs, WARs, and JARs). During this process some validation of the application occurs. If this message was issued something about the application is incorrect. The server will continue to function properly unless an attempt is made to use the indicated application ID. In which case a Bean Meta Data load failure will occur. One possible cause of this problem might be incorrect file permissions on the application directory for the server. User Response: None, unless an attempt was made to use the indicated application. If access to an application was attempted and failed, you need to verify if any permissions were incorrect. There may be a message ICH408I at the operator console and in the job log for the server indicating which file access failed. If the message exists then correct the permissions on the file indicated in the message. If the message ICH408I does not exist, check the directory and file permissions of the application directory. The default name for this directory would be /WebSphere390/CB390/apps/<server name from this message>/A/A<application id from this message>. The permissions should be, at a minimum read and execute for user and group through the complete directory structure for the application. This can be displayed by issuing the following command: ls -lR /WebSphere390/CB390/apps/<server name from this message>/A/A<application id from this message>* from a telnet session to the system or from OMVS on the system. If the permissions are incorrect use the follow command to correct them: chmod -R ug+rx /WebSphere390/CB390/apps/<server name from this message>/A<application id from this message>*. If this is not the problem the next step is to check the server region log for JAVA stack traces that appear before this message. If this is not enough information to determine what the problem is, tracing can be activated to obtain more information. The tracing that should be activated is com.ibm.ws390.sm.*=all=enabled. Refer to the Messages and Diagnosis guide in the section "Steps for turning on J2EE tracing" for how to active tracing for the server indicated in this message. If the additional trace information does not help then an application redeploy may correct the problem. The application name can be determined by issuing the following command: cat /WebSphere390/CB390/apps/<server name from this message>/A<application id from this message>.modules. There will be the words APPLICATION=<app name> displayed to the screen along with information about EJBs, WARs, and JARs in the application. ________________________________________________________________ Chapter 13, pg. 231 (new message) BBOJ0034I APPLICATION ID {0} IN WEBSPHERE z/OS SERVER {1} IS NOT A VALID APPLICATION, FILE {2} IS MISSING Explanation: During WebSphere z/OS server initialization all of the installed applications are checked for the contained modules (EJBs, WARs, and JARs). During this process some validation of the application occurs. If either the application modules or XML file are missing for the indicated application ID, this message is issued. The server will continue to function properly unless an attempt is made to use the indicated application ID. In which case a Bean Meta Data load failure will occur. These files may have been removed by accident, or part of the application information was not deleted from the HFS when the application was removed. User Response: None, unless an attempt was made to use the indicated application ID. If access to an application was attempted and failed, you will need to redeploy the application. If you know the user that experienced the application failure then ask them the name. If the name is not known and either the A<application id from this message>.modules A<application id from this message>.xml file exists in the /WebSphere/CB390/apps/<server name from this message>/A directory then you can issue the cat command on the modules or xml file to determine the application name. If it's the modules file then the application name follows the word APPLICATION=. If it is the xml file the application name is between the words <display-name> and </display-name>. If you can not determine the application that needs to be redeployed call next level of support. If you successfully redeploy the application and you still receive this message call next level of support. Information has to be manually removed from the HFS to resolve this problem. ________________________________________________________________ Chapter 13, pg. 231 (new message) BBOJ0035E WEBSPHERE z/OS SERVER {0} DOES NOT HAVE READ ACCESS TO DIRECTORY {1} Explanation: During WebSphere z/OS server initialization all of the installed applications are checked. To do this requires at least read access to the /WebSphere390/CB390/apps/<server name>/A directory. This message is issued if the server does not have read access to the directory. User Response: Check that the directory permissions are at least read for the user and group. If the permissions are correct, check that the user id assigned to the server is in the group assigned to the directory. If the permissions and group setup are correct then it could be the directory is corrupted. You may be able to correct this problem by doing a redeploy of all the applications in the server. If not call the next level of support. ________________________________________________________________ APAR PQ59714 is associated with SERVICE LEVEL W401054 of WebSphere Application Server V4.0.1 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: UQ65668 Modules/Macros
|
Document Information |
Product categories: Software > Application Servers >
Distributed Application & Web Servers > WebSphere Application
Server for z/OS
Operating system(s):
Software version: 401
Software edition:
Reference #: PQ59714
IBM Group: Software Group
Modified date: Jun 5, 2002
(C) Copyright IBM Corporation 2000, 2006. All Rights Reserved.