| Issue Number | 4174 |
|---|---|
| Summary | Filesweeper - Submit Notification Email on Error |
| Created | 2016-10-20 11:24:01 |
| Issue Type | Improvement |
| Submitted By | Englisch, Volker (NIH/NCI) [C] |
| Assigned To | Kline, Bob (NIH/NCI) [C] |
| Status | Closed |
| Resolved | 2016-10-21 10:28:08 |
| Resolution | Fixed |
| Path | /home/bkline/backups/jira/ocecdr/issue.196679 |
On the DEV server the Filesweeper was running when the server was
rebooted over the weekend. This caused a lockfile to be left causing all
following attempts to start Filesweeper to fail as well.
If possible, we shouldn't just write a message to the log file but also
submit an email notification. The following notification gets written to
the logs:
"It appears that another copy of FileSweeper is currently
running.
Only one copy may run at a time.
If you are certain that no other copy is running, then
manually
remove the file "/cdr/log/FileSweeper.lockfile" to enable FileSweeper to
run."
The software actually was trying to send an email notification about the lock file problem, but the database lookup of the addresses to which the notification should be sent was failing. This was caused by the fact that our DB API layer is built on OLE DB which doesn't play well in multi-threaded environments, and the new scheduler is multi-threaded. I have replaced the use of cdr.getEmailList() with a static method in CDRTask which uses the new DB API layer built on top of pymssql.
This is in production.
Elapsed: 0:00:00.001275