When a MID Server is restarted while there are still xml input records left unsent in the ECCSender folder, the MID Server will run the job a second time. This is due to:
- At the time of restart, there may be XML files in \agent\work\monitors\ECCSender that have not yet been sent back to the instance ECC Queue. This is likely for integrations where data is transferred to the MID Server quicker than the MID Server can transfer it on to the instance.
- The ECC Queue Output records remain in Processing state until the input has been returned to the instance, and the 'ECC Queue - mark outputs processed' business rule updates the output to Processed
- The MID Server will re-process all Output records in Processing state on startup, because Ready and Processing outputs will be fetched.
The target server will have the job run on it twice. 2 ECC Queue Inputs may be returned for the single job, except in this situation:
If the first run of the job is still in the ECCSender folder when the job runs for the second time, you will also see an error similar to this in the MID Server agent log may indicate this problem:
SEVERE *** ERROR *** Failed to rename ECC enqueued item from ecc_queue.16952492a1e0000001.2427354938280329961.tmp to ecc_queue.16952492a1e0000001.xml
In that case the second ecc_queue input will not come back to the instance.
Steps to Reproduce
This is tricky to reproduce on demand without having a setup that routinely causes a backlog in the ECCSender folder.
This issue is under review. If you are experiencing this problem, contact ServiceNow Customer Support.
Related Problem: PRB1330405