After upgrading to Spectrum 9.4, we get an Alarm - Alarm synchronization failed, "SRM Application - REPORT MANAGER: ALARM EVENT PROCESSING FAILURE".
You will see the following entries in the Tomcat logs "<SPECROOT>\tomcat\logs\stdout.log"
16/02/2015 8:58:58 AM (SRM/AlarmHandler/bucketReader) (SRM_Alarms) - (ERROR) - Critical failure with events; processing halted for all servers.
Handler Name: AlarmHandler
16/02/2015 8:59:02 AM (SRM/LandscapeManager/LandscapeThread_0) (SRM_Alarms) - (ERROR) - Unable to properly process handler update.
Domain: <landscape name>
16/02/2015 8:58:58 AM (SRM/AlarmHandler/bucketReader) (SRM_Alarms) - (ERROR) - Error while processing alarm events for <landscape name> Caused by: java.lang.StringIndexOutOfBoundsException: String index out of range: -1 at java.lang.String.substring(String.java:1911) at com.aprisma.spectrum.app.repmgr.dc.event.handler.AlarmHandler.writeToDB(AlarmHandler.java:1957)
If you run below steps to execute SQL query against MySQL reporting database, i.e.
a. From a command prompt, navigate to <SPECROOT>\MySQL\bin folder and execute the below commands:
mysql.exe -uroot -proot reporting
b. Run the following SQL query on mysql prompt
select count(*) from bucketactivitylog where destroy_time is null;
The output shows that the table counts keep on increasing. This count should ideally be zero if the tables are up to date. You will also notice a lot of Alarm Bucket files in the <SPECROOT>\mysql\data\reporting folder as well.
c. Run the following SQL query on mysql prompt
select * from landscape \G;
This would show that the Alarm synchronization is way behind and not catching up with the latest time stamp.
This is a known issue that is fixed via patch "09.04.00.D02" and is included in Spectrum 9.4.2. This patch needs to be installed on the OneClick server which is running SRM (Spectrum Report Manager). Please contact CA support if you need the patch or need any further clarification.