Tungsten Transformation Modules
      Back to home
      1. Knowledge Base and Help Center
      2. Tungsten Automation (Formerly Kofax)
      3. Tungsten Transformation Modules

      Retry or Refresh functionality in the event of a network or operation failure for KTM


      Issue


      Does KTM have a Retry or Refresh functionality in the event of a network or disk operation failure?

      Solution


      Yes. By default, the retries mechanism for the KTM modules is not available. In order to turn it on, the retry interval and the maximum time to retry for must be configured.These parameters are stored in the ACConfig.xml file and need to include theReliableFileSystemelement as a direct child of the ACConfig element, as shown below:


      1    <ACConfig>
      2    ...
      3    <ReliableFileSystem>
      4    <RetryMaxRetrySeconds="120"MilliSecondsBetweenTries="500"MinimumRetries="1"/>
      5    </ReliableFileSystem>
      6    </ACConfig>

      The above specifies that KTM will retry at least once every 1⁄2 second for up to 2 minutes (MaxRetrySeconds: 120).


      The file system Retry works as follows:



        • Config setting changes require application restart.

        • The retry time is measured from the time of the first failure.


        • Retry logic is not based on specific error numbers because they can vary:

            • If the operation is not on a specific file, then it always tries until the retry time expires.

            • If the file does not exist and the drive does exist, then it tries MinimumRetries more times.

            • If the file does not exist and the drive does not exist, then it tries until the retry time expires. If the file exists, then if it is in use, then it tries until the retry time expires.

            • If the file exists and is not in use, then it retries MinimumRetries more times.

      The following table discusses theRetryelement's attributes:

      Attribute Data Type Description Default

      MaxRetrySeconds

      Int32

      This value can be from 0 seconds to 86400 seconds (24 hours) (inclusive).
      The specified value indicates the total time spent retrying a failed file operation starting from the time the operation failed.

      Note that no matter what this setting is (even if it is 0), failed file operations will be retried at least one time. This provides more robust application behavior when there are intermittent network errors.

      Note that the time spent retrying may be longer than specified by the amount of time it takes for the file operation to fail twice.
      If this value is missing, a value of 120 seconds (2 minutes) is used.

      Sites that have a particularly long fail over cycle should increase this value to be longer than the time required to fail over the file system resource. Note that a value larger than 300 seconds (5 minutes) is not recommended because users will not tolerate such a long delay.
      Sites that desire immediate errors when a disk resource is down (as in prior Capture versions) should set this value to 0.

      0, i.e. no retries will be done.

      MilliSecondsBetweenTries

      Int32

      This value can be from 0 milliseconds to 43,200,000 milliseconds (12 hours) (inclusive).
      The specified value indicates the time to pause between retrying failed file operations.

      The default value is 500 milliseconds (0.5 second).
      If the value is greater than MaxRetrySeconds * 1000, then the smaller value is used.

      500

      MinimumRetries

      Int32

      Minimum number of retries to attempt (overriding the MaxRetrySeconds parameter).

      0
      Note-Icon.png

      NOTE:The default behavior for KTM modules (no retries) is different than that for Capture modules (retry every 0.5 seconds for up to 2 minutes). Changes in the ACConfig.xml file will apply to both the Capture and KTM modules.


      Taken from: https://knowledge.kofax.com/Transformation/Reference/Does_KTM_have_a_Retry_or_Refresh_functionality_in_the_event_of_a_network_or_operation_failure%3F