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