HP-UX Event ManagerProgrammer's Guide

NOTE: Not all error codes returned by the connection functions indicate a disconnect.
In particular, the program can drop out of EvmConnWait as a result of a signal. If this is indicated,
the correct action is to return immediately to the EvmConnWait call.
If your program is a posting client, you must deal with a disconnection only if you are using a
permanent connection. For more information about connection, see “Choosing a Connection
Policy” (page 34). You must be sure to examine the return status from EvmEventPost or
EvmEventPostVa, and, if necessary, re-establish the connection and retry the post operation.
Missed Events
In a system with a high level of event activity, a client mav subscribe for many events. In such
a scenario, it may not be possible for the client to receive all the posted events. This happens if
the client takes a long time to process the events — for example, the client that has subscribed
needs to write each event to disk. An example of such a client is the EVM logger, which recognizes
when it has missed events and reports the failure by logging a special “missed events” event. If
there is a danger that your application might miss events, you must ensure that the system is
configured to minimize the risk, and write your programs to handle appropriately.
When the EVM daemon sends an event to a subscribing client, it does so with a connection that
depends upon fixed-size communication (send and receive) buffers. If the client does not handle
the incoming events within a reasonable time, the buffers may be filled because of the heavy
event load. As a result, the EVM daemon cannot send further events. The default receive buffer
size is set to a constant value equal to 1024*128.
As the EVM daemon is a critical resource for many system components and applications, it
cannot block the events while waiting for a client to clear its buffer. Consequently, if it fails to
write to a connection because the buffer is full, the daemon marks the connection as blocked and
continues with its other activities. When the client eventually reads its input and frees space in
the buffer, the EVM daemon completes the failed write and the client will receive the event.
However, if in the meantime, any other events arrive that should be sent to the blocked subscriber,
the daemon does not attempt to send them; instead, it counts how many have been missed and
reports the number to the subscriber when the connection becomes unblocked. The subscriber
must take an appropriate action, but there is no way for it to know which events were missed.
Your application can miss incoming events under extreme circumstances. The likelihood of this
happening depends on the following factors.
• The speed and load of the system
• The set of subscribed-for events
• The frequency with which events are being posted
• The size of the connection's input buffer
• The size of the events being posted
To minimize the risk of missing incoming events, design your application to handle the incoming
events as quickly and efficiently as possible. The application must also take appropriate action
when it is notified that it has missed events. For a sample program that deals with missed events,
see “Dealing with Missed Events” (page 51).
Using Event Filters
An event filter is used to identify the set of events in which you are interested. After it is
established, a filter evaluator is given a string defining the events of interest, and can then be
passed a series of events, returning for each a Boolean indication of whether the event passes
the filter.
Filters are used in EVM subscribing client programs to specify the set of events for which they
want to subscribe, and may also be used in determining the action to be taken for the events they
Missed Events 35