Different information is seen when accessing different Application Servers in an Advanced Availability environment for ITSM

Products

• CA Service Management - Asset Portfolio Management
• CA Service Management - Service Desk Manager

Issue/Introduction

SUMMARY

Different information is seen when accessing different Application Servers in an Advanced Availability environment for ITSM.
Note that the information viewed on the different servers should be identical, if called under the same conditions (Same Contact, Role and interface type, for example.)

EXAMPLE

For example, searching on a Change Order Template list on one server shows 26 results against one Application Server, and 27 results against another Application Server, when using the same Contact and Role.

Checking the physical database shows an invalid row in the change_template table.

Trying to create a New Change Order through the web client interface with this bad row data, gives the following error:

"AHD04819:Error with template: Invalid template. Template not set."

When trying to Edit this Change Order with a template, it gives us the following error: 

"chg_tpl template "Applications" for chg:421491 not found in database"

Environment

Release : 17.1

Component : SERVICE DESK MANAGER

Cause

There is a difference in the cached data held on the different servers.

The underlying root cause will vary depending on the trigger, and may be impossible to determine without verbose logging captured at the time the problem occurs on working and non-working servers.

In this example, the cause of the web client messages was localised to a a bad row of data existed in the physical database, and was reflected differently in the different caches of the servers in the ITSM environment.

Other cache imbalance issues will have different root causes.

Resolution

If the same data appears differently when accessed against different servers, by the same Contact and Role, then it is likely a cache issue.

(If the data was only different when the Role, Contact, Data Partition or other security restriction was invoked, then it is likely an issue in those definitions.)

All cache issues should at a minimum have a refresh of the table data done (or the relevant cache).  However, it is recommended that the basic minimum is a recycle of the ITSM service on each server, as this ensures that the complete system is refreshed and no stray tables are missed.

1) RECYCLE THE ENVIRONMENT 

Recycle the ITSM Services for all servers in the Advanced Availability environment. 

A rolling restart is possible to avoid disruption.

Kill any stray ITSM processes such as java or tomcat.

A recycle of the full servers is another alternative to get a clean start.

Then fully check the system through the interface to make sure that the issue is resolved. Most caching issues will be resolved at this point.

 2) CHECK AND CLEAN UP ANY BAD DATA

This is a separate topic, and will depend on the underlying fault. However, any "bad data" should be cleared up.

In one specific case for example, it was identified that there was a change template row with "NULL "where the id should be. This was cleaned up with a pdm_load to edit the bad change_template row which was missing an "id" and other key data in the database. Then a new Change Order template for the "Applications" template was created, The prior "bad data" was was Inactivated.

CAUTION: Direct database manipulation is only to be done with extreme care. Complete loss of system functionality is possible. Please seek assistance if unsure. It is recommended to try all results in a test environment first, with appropriate backups.
Note that Broadcom Support is not responsible for direct database manipulation.