APAR status
Closed as program error.
Error description
It is possible for a WebSphere Application Server process that
is experiencing an OutOfMemory problem to also experience a sync
failure. This would result in a SOAP RPC timeout error.
In a nodeagent process, the last step in synchonizing config
files is to send a message to all Application Servers. The
OutOfMemory exception could prevent notification, thereby
preventing synchronization. The synchronization fails in this
case and a failure flag is thrown as a result.
This fix separates the sync and Application Server
notification into different threads. This will allow the sync
process to complete, even if Application Servers are not
notified. The Application Servers should not see any
difference unless the client specifically designs the
Application Server, by adding code, to invoke new logic
(which is part of the added code) after notification about
the config file changes is received by the Application Server.
In this case, failure for the Application Server to receive
notification will result in failure to invoke the new logic.
In summary, if a server is experiencing an OutOfMemory problem,
then the nodeagent notification may fail, causing the sync
operation to throw a failure flag.
Local fix Problem summary
****************************************************************
* USERS AFFECTED: WebSphere Application Server for Network *
* Deployment users who have application *
* servers running out of memory. *
****************************************************************
* PROBLEM DESCRIPTION: When there is an application server *
* having OutofMemory problems, it is *
* possible to experience synchronization *
* failures. *
****************************************************************
* RECOMMENDATION: *
****************************************************************
One of the last steps in a synchronization process is to
propagate messages about repository configuration changes to
application servers. The JMX call responsible for doing this
may fail or hang when waiting for a response back from a
problem application server. This could cause the
synchronization process to report a failure result.
However, it is not necessary to have synchronization wait
for the propagation of messages to finish. There are two
separate functions, and they should be treated asynchronously.
Problem conclusion
Improved the synchronization code to send messages about
repository changes asynchronously so its success or failure
does not have bearing on the success or failure of
synchronization.
Temporary fix Comments
APAR information |
APAR number |
PQ93427 |
Reported component name |
WAS NETWRK DEPL |
Reported component ID |
5630A3601 |
Reported release |
00S |
Status |
CLOSED PER |
PE |
NoPE |
HIPER |
NoHIPER |
Special Attention |
NoSpecatt |
Submitted date |
2004-08-27 |
Closed date |
2004-10-15 |
Last modified date |
2005-01-18 |
APAR is sysrouted FROM one or more of the following:
APAR is sysrouted TO one or more of the following:
Modules/Macros
Publications Referenced
Applicable component levels |
R00A PSY |
UP |
R00H PSY |
UP |
R00I PSY |
UP |
R00P PSY |
UP |
R00S PSY |
UP |
R00W PSY |
UP |
R10A PSY |
UP |
R10H PSY |
UP |
R10I PSY |
UP |
R10P PSY |
UP |
R10S PSY |
UP |
R10W PSY |
UP |
|