SLO firing twice after client copy and kicking off even though it was deleted.

Products

• CA Automic Workload Automation - Automation Engine

Issue/Introduction

An SLO object kicks off twice in a client even though it is only defined once.  OR the SLO object continues to kick off even though it has been deleted.

The following was done to move clients into client 100 from a different Automic system:

1. A copy of client 1000 was made in client 50 using unload all objects/load transport case – this was done as a general backup a while ago
2. A copy of client 1000 was made in client 55 this morning using unload all objects/load transport case – this was a daily copy as a backup
3. Client 1000 was deleted and an unload of all objects on another system was used to create a transport case.  Client 1000 was then recreated and the transport case from the other system was loaded into client 1000 on prod

One time when this was done, the same SLO was kicking off notifications twice.  At another point, that SLO object had been deleted from the system but continued to be fulfilled and activate notifications – these notifications also restarted some objects even though they should not have been (because the SLO should not have activated anything when it was deleted)

Environment

Release : 12.3.7

Component :

Resolution

Root cause was not found for this.  It looks like at some point the JWP had a cached value of the original SLO object.  The JWP is the process that keeps track of and processes SLO objects.  When the SLO seemed to be getting fulfilled twice and kicking off double notifications, this would be when the original SLO was cached and the actual SLO was also kicking off notifications.  When we deleted the actual SLO object, the cached SLO was still kicking off notifications.  Since the JWP holds the SLO processes, restarting the server seems to uncache the original SLO object.

If this happens again, the following should be done:

1. Open the Administration perspective in the AWI
2. Right-click a single WP and choose “Advanced Options”
3. Update TCP/IP to 2 and database to 4
4. Make sure “Memory trace” is unchecked and click Apply
   
   
5. Reproduce the issue by having both SLOs kick off
6. Delete the current SLO, run the unload (reorganize database)
7. Reproduce the issue again by having the cached SLO only kick off
   
   
8. Turn off tracing by going to the Administration perspective, right-click a WP, choose “Advanced Options” and click the “Reset Trace Flags” button and click Apply
   
   
9. To recover from the issue, restart the JWP on the system.  If it still does not recover, then please run a restart of the full system again.
   
   
10. Open a case with Support and send:

• • The results of all queries above
  • All WP logs ending in 00.txt
  • All WP traces ending in 00.txt
  • All CP logs ending in 00.txt