PK13497: NODESYNCTASK A ADMS0023I: A SYNCHRONIZATION OPERATION REACHED THE ITERATION LIMIT | |||||||||||||||||||||||||||||||||||||||||||
![]() |
|||||||||||||||||||||||||||||||||||||||||||
![]() APAR status Closed as program error. Error description NodeSyncTask A ADMS0023I: A synchronization operation reached the iteration limitLocal fix Problem summary **************************************************************** * USERS AFFECTED: All users of WebSphere Application Server * * V5.0 for z/OS * **************************************************************** * PROBLEM DESCRIPTION: Message "ADMS0023I: A synchronization * * operation reached the iteration limit" * * may be issued during a node * * synchronization which otherwise * * reports successful completion. * **************************************************************** * RECOMMENDATION: * **************************************************************** Intermittent problem during node synchronization. When many files have been updated, a modified serverindex.xml doesn't get pulled from the dmgr. This leaves the node's config in a corrupted state because the servers listed in serverindex.xml are not the same ones in the config structure. The only remedy is to perform a synchNode manually, after which everything goes back the proper state. This "improper" synchonization has been seen only with the serverindex.xml file and only during deletion of servers and clusters. After the incomplete synchronization occurs the dmgr no longer recognizes the nodeagent when it starts up. This message appears in the log: NodeSyncTask A ADMS0023I: A synchronization operation reached the iteration limit. This was because of the hardcoded iteration limit in NodeSyncTask. This limit had to be increased from 3 to 5Problem conclusion In order to avoid having to block updates to the master repository while a sync operation is taking place, the sync operation has been made iterative. At the end of a sync operation the sync service checks the master repository to see if it was updated while the operation was taking place. If it was, then the sync is not complete and it restarts from the beginning. There was an iteration limit of 3 in order to recognize periods of high repository update activity. So if the iteration limit is hit the sync operation will be declared failed. Once the churn in the repository has settled, the next sync operation should complete normally. This has been the sync behavior since the very beginning of 5.0 and this is the first time we encountered the iteration limit. Since there is no control provided for the iteration limit, the only recourse is to request another sync after the repository updates have subsided or wait for the sync interval to expire which will kick off another sync. This limit has now been raised to 5 instead of 3. APAR PK13497 is associated with SERVICE LEVEL W502036 of WebSphere Application Server V5.0 for z/OS.Temporary fix Comments
APAR is sysrouted FROM one or more of the following: PQ94708 APAR is sysrouted TO one or more of the following: PK13498 PK13499 Modules/Macros
Publications Referenced
|
Document Information |
Current web document: swg1PK13497.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 #: PK13497
IBM Group: Software Group
Modified date: Dec 7, 2005
(C) Copyright IBM Corporation 2000, 2009. All Rights Reserved.