Specifications
9032277-04 Software Superseded by CS3/MMS3
5-83
Patches Issued Since the CS2/MMS2 Release
action, i.e. anything that's capable of DMF, AutoDiscovery will do
nothing, and the Management Module will set up the Collects
relationship with their topologically significant models. For the
SS6000, this will be all the blades, for the 9AXXXX-XX boards, this
will be the SFSmartCell.
--
The problem was when a socket to a SpectroSERVER was blocked,
new alarms from that server stop showing up in clients which show
alarms. Cleared alarms persist. The following scenario describes the
problem:
There are servers A and B, and A is modeling B. There is an
Enterprise Alarm Manager launched from a graph-only machine or
from the server A machine itself (from the command line or from the
GUI) against server A, and its filter is set up to show alarms from both
A and B. Call this client 1. The view is dynamic for both server A and
server B, in that new alarms show up when they are asserted and
disappear when they are cleared. Another EAM is launched (from the
command line) from another graph-only machine against server B, in
which only server B's alarms are shown. This is client 2. This view
updates dynamically, as designed.
At some point, a third client opens a socket to server B. The client
could be EAM or vnmshd (there might be more which we have not
witnessed). This third client's socket becomes blocked, for whatever
reason.
At this point, client 1 and client 2 stop showing updates for alarms on
server B. A CLI show alarms shows new alarms which are not
showing up in EAM. Also, EAM is showing old alarms, which
according to CLI have been cleared. On client 1, alarms for server A
are still showing up properly.
Once client 3 is killed, clients 1 and 2 begin to dynamically show
alarms for server B
The resolution was to add a timeout on write requests in
CsBlockingCif. This will be settable via the .vnmrc
("send_message_timeout"), with a default setting of 180 seconds (3
minutes). Therefore if one client's socket is blocked, updates may be
delayed for 3 minutes, at which time the rogue client's socket will be
closed and normal updates will resume. This allows the VNM to
resume alarm updates after a delay.