PK00451: Z/OS WEBSPHERE TIME DELAYS WITH STARTING/STOPPING APPLICATIONS WITH A MULTI-SERVANT APPLICATION SERVER ENVIRONMENT. | |||||||||||||||||||||||||||||||||||||||||||
![]() |
|||||||||||||||||||||||||||||||||||||||||||
![]() APAR status Closed as program error. Error description On z/OS WebSphere version 5.0.x only, customer might experience a time delays with starting/stopping applications with a multi-servant application server environment. .. In trace you will see We see that ControlAdminServiceImpl.getConnectorRequest invokes JMXPitchDirector.getRequest. You will see a NullPointerException in the ORB trace buffer. .. Example: ======= Trace: 2004/12/20 14:19:00.884 01 t=9A7088 c=UNK key=S2 (0404806E) Description: CorbaInvoke - Marshalled response Method Name: ORBEJSBridge::CORBAinvoke(void*) Buffer: data_address=45a30fec, data_length=132 -------------------------+ | ASCII | --------+----------------+ |....IDL:omg.org/| |CORBA/UNKNOWN:1.| |0.00..W......000| |.......ERMI:java| |.lang.NullPointe| |rException:5E241| |5FE96422431:47A5| |A18EFF31E1B8.38.| |.... | .. You will also see the ControlAdminServiceImpl.getConnectorRequest method call the JMXPitchDirector.getRequest. .. Example: ======= Trace: 2004/12/20 14:19:00.845 01 t=9CAE88 c=UNK FunctionName: com.ibm.ws390.management.connector.pitch.JMXPitchDelegate SourceId: com.ibm.ws390.management.connector.pitch.JMXPitchDelegate Category: DEBUG ExtendedMessage: About to invoke getConnectorRequest .. In the JMXPitchDelegate (within the servant) before the NullPointerException, WebSphere is about to invoke ControlAdminServiceImpl.getConnectorRequest. .. If you take a look at the beginning of the processof JMXRequest method, you would see that before calling "ControlAdminServiceImpl" ("About to invoke getConnectorRequest") there were no tracing information after the return from ControlAdminServiceImpl was issued. .. Hence causing a time delays with starting/stopping the servers. The controller was timing out for 3 minutes after it did not get a response from 2 servants as it expected. The servant that gets a "null" request queued was not expected to respond anyway, but the count was off, so the controller never got signalled out of its wait.Local fix Problem summary **************************************************************** * USERS AFFECTED: All users of WebSphere Application Server * * V5.0 for z/OS * **************************************************************** * PROBLEM DESCRIPTION: Unreasonable time delays while * * starting/stopping applications in a * * multi-servant application server * * environment. * **************************************************************** * RECOMMENDATION: * **************************************************************** Starting and stopping deployed applications in a multi-servant application server environment causes the administrative console to wait for a long time before the request is processed. The same operation in a single servant configuration completes quickly.Problem conclusion The delays being caused by a timeout hit in the request/response route to multiple servants have been resolved. APAR PK00451 is associated with SERVICE LEVEL W502024 of WebSphere Application Server V5.0 for z/OS.Temporary fix Comments
APAR is sysrouted FROM one or more of the following: APAR is sysrouted TO one or more of the following: Modules/Macros
Publications Referenced
|
Document Information |
Current web document: swg1PK00451.html
Product categories: Software > Application Servers >
Distributed Application & Web Servers > WebSphere Application
Server for z/OS
Operating system(s):
Software version: 500
Software edition:
Reference #: PK00451
IBM Group: Software Group
Modified date: Mar 1, 2005
(C) Copyright IBM Corporation 2000, 2009. All Rights Reserved.