Server restart - Community - Arcana Development

Good morning Bill.

The last couple of month we had problems with adTempus jobs being triggered based on a new/modified files which are not new. Thousands of jobs where triggered. I was not happy :-). Most of them failed because there were to many instances.

We have adTempus 4.6 running on our production server (Windows-2016 Standard), with the SQL-DB on a separate server. The data is on a separate drive (E:).

Every month, there is a Windows-update windows in our company, which will perform updates on the system and will reboot if needed. It looks like Windows takes it's own update time to perform these updates.

The resources from the server are limited and I find 4 VMware Virtual disk SCSI Disk Devices.

What I think is, that after a restart, adTempus is started, before the E:-drive is available, and after some time, when the drive is available, adTempus finds the thousands of new files.

I think we need to adjust the way we perform the restart of the server. There is a heavy system load. One of the reasons is 15 Micro Focus regions which need to be started, handling the jobs triggered by adTempus. My questions:

1) When a shutdown/reboot is activated, do I need to do something with adTempus before hand? Sometimes I get an alert saying that adTempus was not properly closed?

2) What's the best way to handle reboots and how to start adTempus. Normally adTempus will start automatic, but maybe it should be done in another way?

Thanks for any advice,

Kind regards,

Guy

Hi, Guy.

The File Trigger works by scanning the target folder and comparing results on each scan. If there are files there that weren't there on the previous scan, it treats them as new. So in your case it's scanning this drive while the files aren't there (or aren't visible) and then it scans again and they are, so it thinks they're new.

However, it does check for missing drives first: if it tries to scan your files on the E: drive and doesn't fine the E: drive, it should abort the scan and keep the previous scan results (i.e., from an earlier scan when the files were still there). If this is happening, you should see a warning message in the Alerts view in the console with message code 5428 telling you that it can't find the drive.

You shouldn't need to do anything with adTempus during shutdown. If you're getting a warning that it shut down unexpectedly, then it could be that the service control manager is terminating adTempus before it has time to finish doing an orderly shutdown when it gets the shutdown signal.

You could change the service startup to manual and only start it once you know the E: drive is available, but again, adTempus should be detecting that problem already (unless that drive letter is getting assigned to some other drive first?)

To figure out what's going on, you should turn on debug logging for the adTempus service as described here. The next time the server restarts, wait until things are up and running, then make a copy of all the log files and open a support case so we can look at them. We should be able to see what's going on with the scans, and come up with a solution. Perhaps we need to make a change so adTempus "remembers" files longer, rather than forgetting them if they're missing from a single scan of the folder.

Meanwhile the best way to avoid the problem is to have the files moved to a different folder once they've been processed, if possible, rather than leaving them in the trigger folder.