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”.