How errors affect pending items
The DSO server reads items from the distributed pending queue and performs the specified operation (transfer, update, return, or delete) for each item. By default, the DSO server checks for new pending items at the following times:
- When an internal signal mechanism triggered by workflow alerts the server.
- Automatically at two minutes after every hour, ensuring that all pending items are processed if the internal signal mechanism fails.
For information about when polling DSO servers and pools check for requests, see these sections:
If an item succeeds or if it fails with a nonrecoverable error, it is removed from the distributed pending queue. (You can configure DSO to move pending items that fail with nonrecoverable errors to the Distributed Pending Errors form. See Logging failed pending items.)
By default, if a pending item fails with a recoverable error, such as an unavailable target server, DSO periodically retries the item as follows:
- Every 5 minutes for the first 30 minutes
- Every 30 minutes after the initial 30 minutes for up to 24 hours
- Every hour after the first 24 hours
To specify whether the Status value of failed items remains set to New or is changed to Retry, set the Mark Pending Retry field in the AR System Administration: Server Information form. (See the definition for "Mark Pending Retry" field in AR System Administration - Server Information form - DSO tab.)
To limit the number of times the item is retried, change the default Retries value in the distributed mapping. See the definition for "Retries" in Creating distributed mappings.
If you specify values in the Retries "Try for Maximum of Hours/Minutes " option and the specified time limit elapses, the item is removed from the distributed pending queue. This occurs even if one or more retries were not attempted. In this case, if the item includes a Transfer Status or Update Status field, it is set to Timeout.
By default, the system allows three minutes of connection time for processing each distributed operation. This might be an insufficient amount of time in some situations and might cause pending distributed operations to fail. See Configuring the RPC timeout setting.