On 08/12/2015 02:00 PM, Laszlo Ersek wrote: > Assume there has been a long period of silence (no attempts to emit an > event). Now some client code makes a call to emit the event. > > Will that event be emitted immediately, or will it be delayed to see if > more are coming? I'd like to understand this aspect first. > > I think the first instance of the event, after the grace period, should > be emitted immediately, and further instances that quickly follow should > be suppressed.
That has always been the goal of event throttling: when a new event arrives and the timer is not running, emit it right away and start the timer. If another event arrives while the timer has not expired, save it. If multiple events arrive during the timer, the last one received overwrites any others. Then, when the timer expires, either there is a saved event (one or more events arrived during the throttling window), so we send it and restart another throttling window, or there was no event pending so the line is quiet and the next event can send right away. Thus, management will get notification as soon as possible that events are starting to happen after a period of quiet, but will then not be spammed any faster than once per throttle period (once per second) with additional events. When additional events are sent, they are always the most accurate state of the system at the time the event was queued, but intermediate events may have been lost. Furthermore, unless the events have not been happening, the throttling of the event means the management might not see the event until nearly a second late, although the timestamp associated with the event should still be accurate to the time it was queued up, not finally sent. -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature