Re: [Qemu-devel] [RFC 1/3] monitor: split MonitorQAPIEventState

[Eric Blake]

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