PQ59714: IN WAS/390 V401, WHEN MANY EJBS ARE DEPLOYED, SR INITIALIZATION TAKES VERY LONG TIME TO COMPLETE CLASSLOADING

 A fix may be available

Obtain the fix for this APAR



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 information
APAR number PQ59714
Reported component name WASKBASE
Reported component ID 5655A9801
Reported release 401
Status CLOSED PER
PE NoPE
HIPER NoHIPER
Submitted date 2002-04-04
Closed date 2002-05-01
Last modified date 2002-06-05

APAR is sysrouted FROM one or more of the following:

APAR is sysrouted TO one or more of the following:
UQ65668

Modules/Macros
BBOUBINF BBOZ0229 BBOZ0812 BBOZ0813    

Fix information
Fixed component name WASKBASE
Fixed component ID 5655A9801

Applicable component levels
R401 PSY UQ65668    UP02/05/04 P F205

  Fix is available
Select the PTF appropriate for your component level. You will be required to sign in. Distribution on physical media is not available in all countries.


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