1. Alarm “CLIENT APPLICATION NOT RESPONDING TO UPDATES” is based on event 0x10f17 (OneClick performance).
(screen shot 1)
In customers environment you can see event 0x10f14 created as well before event 0x10f17 in the Event tab of the VNM model.
(screen shot 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 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:
(screen shot 3)
Customer 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.
(screen shot 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 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.