We experienced a strange crash of VisualCron this morning with no messages in VisualCron server log or in Windows log. The service was running but clients were thrown off and could not connect. We tried to stop the service but had to kill the process. Before trying to stop the service the log continually reported this message:
Debug ReceiveMail->Mail poll skipped because it was busy receiving email ('Email trigger'), hashcode: <some numbers>
Anyway when we started the service the startup seemed to hang at the log line "Compacting local DB" (in the VC server log). We looked up a similar pattern in an earlier log file. We found out that several months ago the server had also reported "Compacting local DB" while running jobs and the process had taken around 40 minutes. So we waited 40 minutes and the startup continued and the server came up (phew!). Here are the unedited log entries:
4/11/2019 9:21:03 AM Debug Compacting local DB - start
4/11/2019 9:21:03 AM Debug DBConnStateChanged: Open -> Closed
4/11/2019 10:02:09 AM Debug DBConnStateChanged: Closed -> Open
Until a new version last summer i think the VisualCron server has always taken around 10 minutes to start up (all inclusive), but the start process has afterwards been improved, so it was possible to logon before the whole start process had finished.
Question: We have probably been very unlucky today but why wait for the compact process to finish before the rest of the startup proceeds?
Server/Client: 8.4.1 on Win2008R2.