Release notes and documentation updates for 3.5.4
- Release notes update
- Update openapi info.version to 3.5.4
- Update scheduled-tasks docs to reflect changes in retry mechanism
- Update deployment docs to update configurable timer parameters
- Remove unused locked-module-sync.sleep-time-ms
Issue-ID: CPS-2457
Signed-off-by: danielhanrahan <daniel.hanrahan@est.tech>
Change-Id: Ieb559bbfe348848c4b8669410861edfeeb6c9bf3
diff --git a/docs/cps-scheduled-processes.rst b/docs/cps-scheduled-processes.rst
index 032b4b1..c204e6c 100644
--- a/docs/cps-scheduled-processes.rst
+++ b/docs/cps-scheduled-processes.rst
@@ -22,9 +22,11 @@
-----------
The module sync is a user :ref:`configurable timed process<additional-cps-ncmp-customizations>`,
which is set to search for CM-Handles within CPS with an *'ADVISED'* state.
-Once the CM-Handle(s) is processed by the module sync, the CM-Handle state is then set to *'READY'*, if the process completes successfully.
+Once the CM-Handle is processed by the module sync, the CM-Handle state is then set to *'READY'*, if the process completes successfully.
If for any reason the module sync fails, the CM-Handle state will then be set to *'LOCKED'*,
and the reason for the lock will also be stored within CPS.
+CM-Handles in the *'LOCKED'* state will be retried when the system has availability. CM-Handles in a *'LOCKED'*
+state are processed by the retry mechanism, by setting CM-Handle state back to *'ADVISED'* so the next sync cycle will process those again.
Data Sync
---------
@@ -33,13 +35,3 @@
Once the CM-Handle(s) with a sync state of *'UNSYNCHRONIZED'* is processed by the data sync,
the CM-Handle sync state is then set to *'SYNCHRONIZED'*, if the process completes successfully.
If the data sync fails, the CM-Handle sync state will remain as *'UNSYNCHRONIZED'*, and will be re-attempted.
-
-Retry Mechanism
----------------
-The retry mechanism is a user :ref:`configurable timed process<additional-cps-ncmp-customizations>`,
-which is used to search for CM-Handles which are currently in a *'LOCKED'* state.
-If the CM-Handle is ready to be retried then, the CM-Handle(s) in a *'LOCKED'* state is processed by the retry mechanism,
-the CM-Handle state is then set to *'ADVISED'*.
-Whether the CM-Handle is ready to be retried is dependent on both the number of attempts to sync the CM-Handle,
-and the last update time of the CM-Handle state.
-With each new attempt to unlock the CM-Handle, the time until the CM-Handle can next be retried is doubled.