CLIENT APP NOT RESPONDING TO UPDATES

Products

• CA Spectrum
• Network Observability

Issue/Introduction

Customer is receiving alarm “CLIENT APPLICATION NOT RESPONDING TO UPDATES”, on a few OneClick servers.

Customer knows of connection issues and would like to understand how this alarm is created and cleared with the following questions:

 

1. What exactly causes this alarm to be generated?

2. What exactly causes this alarm to be cleared?

3. What is the impact of this alarm? I don't see a discrepancy in alarms from the affected OC Server.

Environment

DSS with several OneClick servers

Resolution

1.   Alarm “CLIENT APPLICATION NOT RESPONDING TO UPDATES” is based on event 0x10f17 (OneClick performance).

(screenshot 1)

 

In a customer's environment, you can see event 0x10f14 created as well before event 0x10f17 in the Event tab of the VNM model.



(screenshot 2)

 

Answer: Regarding the “cause” of this alarm, can be seen in the “Probable Cause” section in upper “screen shot 1”, like :

------------------------

1) The client application is too busy to respond or is low on resources.

2) The network is not delivering the updates.

3) The network is not delivering the updates in a timely fashion.

------------------------

 

2.   The alarm (based on “0x10f17”) is user clearable because the user can decide if this is important (keep alarm without clearing) or known (clear alarm).

 

On some landscapes in the DSS you can also see event 0x10f15 created after 0x10f14, which would then clear also 0x10f17, in case it was already created after 180 seconds (event pair rule) of event 0x10f14: 

(screenshot 3)

 

Customers can see that for some landscapes alarm/event (0x10f17) created and was not cleared automatically, but with a Spectrum Tomcat restart of the OneClick server. The reason for a Spectrum Tomcat restart to clear the alarm is the situation that event 0x10f16 is created after the Tomcat is back, but this was not seen by the customer, as 0x10f16 is not locked in the Archive Manager. But it is an explanation that the “workaround” to automatically clear the alarm is a Spectrum Tomcat restart.

(screenshot 4)

 

3.   The alarm itself is just to show that there is a connectivity issue present between the SpectroServers and the OneClick server. The alarm is user clearable, because if it would be cleared by Spectrum, then the user/admin would not notice it. The alarm is basically a “fail save”, so connectivity issues are seen, as it happens for a longer period and should make the user/admin aware.

It should help the admin to follow up on the issue and make sure that this is not happening all the time, as it will prevent Spectrum from displaying correctly what is monitored by the SpectroServer.