Eric Blake <ebl...@redhat.com> writes: > On 09/28/2015 02:38 AM, Markus Armbruster wrote: > >>>> +++ b/docs/qmp/qmp-spec.txt >>>> @@ -175,6 +175,11 @@ The format of asynchronous events is: >>>> For a listing of supported asynchronous events, please, refer to the >>>> qmp-events.txt file. >>>> >>>> +Some events are rate-limited to at most one per second. If more >>>> +events arrive within one second, all but the last one are dropped, and >>>> +the last one is delayed. Rate-limiting applies to each kind of event >>>> +separately. >>> >>> Do we also want to document that limits might be further tuned according >>> to other elements of the event, with VSERPORT_CHANGE "id" as the example? >> >> You need to interpret "each kind of event" in a sufficiently fuzzy >> manner :) >> >> Seriously, I'm open to suggestions for better language here. > > Maybe: > > Some events are rate-limited to at most one per second. If more events > of the same type (along with any other fields that an event documents as > being significant) arrive within one second, ... > > or: > > Some events are rate-limited to at most one per second, either for the > event type in general, or additionally considering other significant > fields as documented by a specific event. If more equivalent events > arrive within one second, ... > > But since you did point out that VSERPORT_CHANGE mentions the filtering > on "id", I guess I won't try too much harder to paint the bikeshed any > further.
I'll use this for inspiration when I prep the non-RFC patch. Thanks!