Loading...
Loading...
The following Java System properties can be set to configure how the channel synchronization process works:
| Property | Default | Description |
|---|---|---|
| mirth.clustering.channelsync.initialwaittimems | 60000 | The initial amount of time that the sync process will wait for channel tasks to finish before moving on and releasing the channel operation lock. Default is 1 minute (60000 ms). |
| mirth.clustering.channelsync.maxwaittimems | 600000 | The maximum amount of time that a particular channel task will be allowed to run before it gets cancelled. Default is 10 minutes (600000 ms). |
| mirth.clustering.channelsync.resetfailedtaskms | 86400000 | When the maximum amount of failed attempts has been reached for a task, this setting determines how long to wait before resetting those attempts so it can start trying again. If you set this value to 0, these attempts will never be reset unless by a Redeploy All Channels task. When you perform a Deploy/Start/Resume task and it's successful, it will also reset the attempt counts for that specific task (for that specific channel) on the server where it was successful. Default is 1 day (86400000 ms). |
| mirth.clustering.channelsync.maxattemptsonfailure | 10 | The maximum amount of attempts the sync process will attempt a particular task (unique action, channel ID, and metadata ID) before giving up and not allowing that task to run again. If you set this value to 0, all tasks will keep trying forever. Default is 10. |
| mirth.clustering.channelsync.maxlogsonfailure | -1 | When a particular task (unique action, channel ID, and metadata ID) fails, the maximum amount of times errors will be sent to the server log. When this maximum is reached for a particular task, logs will still be sent under the DEBUG level. Alerts and server events will still always be sent. If you set this to 0, errors will never be sent to the server log. Default is -1, meaning errors will be always be sent to the server log. |
| mirth.clustering.channelsync.maxlockattempts | 20 | It's possible that a Remove All Messages or message recovery task could be running/stuck for a long time. If that happens, we want to make sure we're still able to run the synchronization process, even if it's on a longer cadence. So we try to acquire the lock and if it fails this amount of times, we allow this process to run anyway and reset the attempt count. If you set this value to 0, there will be no attempts and the startup deploy lock will wait indefinitely, meaning there is a chance this channel synchronization process will never run if that lock never gets released. Default is 20, meaning with an interval of 30 seconds, if the startup deploy lock is stuck or held forever by some other server/process, then the channel synchronization process will run once every 10 minutes. |
| mirth.clustering.channelsync.maxupdatecounterattempts | 1 | When there are updates to the desired channel states made in the cluster, the cluster nodes will see the changes in the next synchronization interval and change their channels states to match, but it is possible that the desired channel states haven't been fully updated yet so the nodes will wait until a later update interval, checking desired channel states again until there are no further changes. At times, desired channel states could be changing quite often which would cause nodes to continue waiting to update their states longer than is acceptable. This option provides a limit to the amount of times a channel synchronization process is skipped. At most it will be skipped maxupdatecounterattempts. If you set this to 0, synchronization will never be skipped. If you set this to -1, synchronization always be skipped and continue waiting until desired channel states have no longer changes within a synchronization interval. |
These properties can be set using the -D option in your *.vmoptions file, for example:
-Dmirth.clustering.channelsync.maxattemptsonfailure=20 |