Any manual changes in the master repository will be picked up and brought down to the node. If you reset the node repository, then any manual changes to the local node files will be wiped out (overwritten) by whatever is in the master cell repository, regardless of whether the cell repository was changed or not. If you reset the master cell repository, then any manual changes made in the master configuration repository will be picked up and replicated to the nodes where the file is applicable. You can reset either the master cell repository epoch or the node repository epoch. There is a JMX operation on the ConfigRepository MBean that resets the repository epoch so that the next sync operation will result in recalculating the file digests and picking up any manual changes to the master cell repository configuration files. This was a compromise reached to allow best performance under normal conditions since editing the files manually is not a recommended best practice.īut manual edits of configuration files in the master cell repository can be picked up if the repository is "reset" so that it goes back out and re-reads all the files and recalculates all of the digests. So, by DEFAULT, manual edits to the configuration files in the cell repository are not picked up during "normal synchronization" operations. The files are not read on every synchronization operation. The algorithm for synchronization by default only compares these epochs between node agent and deployment manager. If a change to a configuration file is made by editing the file and bypassing the administration programs, then the digest is not recalculated because the epochs for the directories continue to match. If the epochs for corresponding node and cell directories do not match, then the digests for all files in the directory are recalculated, including that changed file. During configuration synchronization operations, if the repository epoch has changed since the previous synchronization operation, then individual folder epochs will be compared. If a change to a configuration file is made through the administration programs (Administration console, wsadmin, or other), then the overall repository epoch and the epoch for the folder in which that file resides is modified. These epochs are used to determine whether any files in the directory have changed. These digest values are stored in memory.Īlso stored in memory are "epochs" for the folders in the repository and for the repository overall. How does synchronization actually work? Does the synchronization service synchronize changes to the master repository made by manually editing a configuration file, for example, using Notepad?īoth the node agent and deployment manager keep a calculated digest for each file in the configuration they manage (master cell repository managed by deployment manager, local node repository managed by node agent).New or updated documents are copied to the node repository, and deleted documents are removed from the node repository. This service runs in the deployment manager and node agents, and ensures that the configuration changes made to the cell repository will be propagated to the appropriate node repositories.ĭuring a configuration synchronization operation, a node agent checks with the deployment manager to see if any configuration documents that apply to the node have been updated. The file synchronization service is the administrative service responsible for keeping the configuration documents that are distributed across the IBM® WebSphere® Application Server cell up to date. Each node also has their own local configuration files. The Deployment Manager will maintain a centralized repository of configuration data.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |