12.3.15 Testing Outbound Stream Event FiltersOnce you have set up the event filter for an outbound stream, use the testevent command to check that the filter works according to your plan. The testevent command returns a message specifying the action of the filter used. For example:
If successful, this command returns an informational message showing which filter will be used and what action will be taken if the given event is posted.
The testevent command only analyzes the filter definitions for the outbound stream entity. It does not attempt to establish a connection to the event sink that will actually accept events from the specified outbound stream. Therefore, you can use the testevent command any time after you define a filter, even if the event sink does not yet exist.
The testevent command might reveal an error in your logic
about event filtering for this outbound stream. If this occurs, see
Section 12.3.15.1.
You cannot directly modify an event filter definition entry. If the testevent command described in the preceding section reveals that your filtering scheme is behaving differently from your intentions, you have four options:
Option 1
You cannot use this option to fix filter definition logic errors made in the specific filter. Corrections for the first option cover the simple cases and apply only to overriding logic errors made in the global filter and, to a lesser extent, in the catch-all filter's single value, pass or block. The following example shows one such definition:
If your actual intent was to block all routing circuit ether-2 circuit change events and let all other routing circuit events pass, you could enter the following subsequent commands:
Option 2
See Section 12.3.5 for information about defining filters on event sinks.
Option 3
For cases where the defined filter performs an undesired action, especially at the specific filter, your best option is to record the current, valid outbound-stream event filter definitions, record the other outbound stream parameter values, delete the outbound stream, and redefine it. Use the NCL command-logging function and the show command to record the outbound stream entity definitions you want to use again in the redefined entity. For example:
Confirm that the outbound-stream state status attribute is set to OFF:
If the state is set to ON, select an appropriate time when the outbound stream can be temporarily turned off and use the shutdown command, which is described in more detail in Section 12.5.3. If the state is set to on connected, on connecting, or on shutdown requested, select an appropriate time when the outbound stream can be temporarily turned off and use the disable command described in Section 12.6.1. When the outbound stream entity's state is OFF, delete the outbound stream. For example:
Finally, use a text editor to modify the former outbound-stream characteristics that were recorded in the output NCL command file. Correct the event filter definitions and run the updated command file. For example:
Option 4
To delete the old filter values and reinitialize them to their original default values when the outbound stream was created, use the following command:
New filter values take effect for the next event message sent by the
event dispatcher to the outbound stream.
The following example enables a user-specified outbound stream named netmgr1_obs:
12.3.17 Modifying Outbound Stream CharacteristicsYou can modify all outbound stream characteristics at any time by using the set command. Other changes, such as changing the sink node, require you to disable and then re-enable the outbound stream before the change takes effect. The following example uses set commands to change several parameters for outbound stream netmgr1_obs. You can enter consecutive set commands or include any combination of modifiable characteristics, separating each item with a comma.
In the previous example, the set command performed the following on the existing definition of the netmgr1_obs outbound stream:
The set command also can modify the sink address,
sink end user, sink node, and sink object
characteristics.
When the outbound stream is created and its characteristics set to your satisfaction, and the corresponding event sink is created, defined, and enabled, you can enable the event stream, as the following example shows:
The outbound stream immediately tries to connect to the sink when you enable the outbound stream. If you cannot establish the connection to the sink, the outbound stream tries again after the connect retry timer expires. By default, the connect retry timer is enabled, and its value is 120 seconds. You can attempt an immediate connection with the connect command.
The sink can now receive event messages from the outbound stream and
report them to the sink client.
The following example shows a typical event report. Note that event reports can differ because of the information they contain.
12.5 Managing a Connection Between an Outbound Stream and an Event SinkYou have the option of manually controlling the connection between an outbound stream and its event sink. Three NCL commands allow you to manage connections:
12.5.1 Establishing a ConnectionAfter the outbound stream is enabled, the event dispatcher automatically attempts to establish a connection to the sink when the connect timer enabled characteristic is set to its default value of true. Set this value to false if you want to manually create the connection between an outbound stream and its sink partner. When the connect timer enabled characteristic is set to false, the connect retry timer is not used, as the following example shows:
When the event dispatcher executes the connect command, it looks up the values of the following outbound stream characteristics in the order shown below and uses the first value that is not null.
If the sink object, sink node, and sink address are
all null, the event dispatcher assumes the sink is on the local system
and uses the sink end user characteristic when attempting a
local connection.
If you want idle connections disconnected automatically, assign a non-zero value to the disconnect timer attribute for the outbound stream. You can terminate the connection at any time by using the disconnect command. Note that the disconnect command deletes the connection immediately. This might cause events in transit to be lost. Issue this command only if you have problems with the sink node and want to specify an event sink on a different, functioning node. For example, assume that the event sink for outbound stream netmgr1_obs is located on .admin.netmgr1. With little advance notice, you learn that the sink node will be unavailable starting in approximately 5 minutes. You can use an already existing event sink that resides on a different system. On an OpenVMS system, this event sink can be located by DECdns using the .admin.event_sinks.alternate_sink object name, as the following example shows:
You can also locate this event sink by using the .admin.netman2 sink node name, as the following example shows:
12.5.3 Shutting Down a ConnectionTo perform an orderly shutdown of a connection between an outbound stream and its sink partner, use the shutdown command:
An orderly shutdown ensures the following:
There might be a delay before the shutdown completes. The outbound stream enters the "On Shutdown Requested" state and finishes transmitting all events on its queue to the event sink before shutting down. An outbound stream remains enabled when there is no connection to an event sink. The absence of a connection might be caused by the following:
Because the outbound stream is enabled, it will read event messages from the event dispatcher queue, filter events, and perform all its functions when a connection is not established. Event messages queued to the outbound stream might exceed the buffers used by the outbound stream and might result in events being lost. A special event called an events lost event is inserted into the event stream to indicate that one or more events could not be posted due to buffer overload at the outbound stream. The event dispatcher and event sink also use events lost. Examine event message to determine the source.
Use the shutdown command as part of the system's orderly
shutdown process.
The following sections describe how to disable and delete event dispatcher entities.
To disable the event dispatcher entity, first disable all the
children/subentities, that is, outbound stream, phase IV
relay and sink subentities. If any one of these
subentities is enabled, the disable event dispatcher directive
fails. An error message might state that the outbound stream
entities are still enabled. Other subentities might be enabled besides
the outbound stream entity.
Using the disconnect (see Section 12.5.2) or shutdown (see Section 12.5.3) command with an outbound stream deletes only the connection between an outbound stream and its sink partner. The outbound stream is still enabled. To disable the outbound stream, use the disable command, as the following example shows:
When you enter the disable command, an existing connection between the outbound stream and its event sink is deleted. Simultaneously, the inbound stream is also deleted. By default, the system performs an orderly shutdown. Whenever possible, DIGITAL recommends that you perform orderly shutdowns of event stream connections. If necessary you can abort the connection immediately with the following command:
When the disable command completes, the outbound stream's state status attribute is set to OFF. Once this condition exists, you can activate the outbound stream again by issuing enable command, or you can delete the outbound stream. To delete an outbound stream, its state status has to be set to OFF. Then you can issue the following command:
12.6.2 Disabling and Deleting an Event SinkBefore deleting an event sink, use the disable command to set the sink's state status attribute to OFF:
Disabling a sink terminates any existing connections with outbound streams. It also deletes all the inbound stream subentities corresponding to this sink. After disabling a sink, you can activate the event sink again by issuing the enable command. Or you can delete the event sink. To delete an event sink, its state status has to be set to OFF. Then you can issue the following command:
|
|