amqp — archive

[management] Proposal for event notifications (initial outline)

From: Alan Conway <[email protected]>
To: [email protected]
Date: Fri, 13 Feb 2015 18:13:00 -0000

On Fri, 2015-02-13 at 10:26 +0100, [email protected] wrote: > Hi Alan, > > I think this would be very useful addition to the management spec. > > But I'm not sure I like the way how you link the eventType with the > entityType. Is there any particular reason why you want to have the > entityType included in the eventType? Why not have them as two separate > attributes, where the entityType would be optional? Yes, that was half-baked. I should have applied the rule "when you say MAY, better throw it away!" Lets drop that and just say: "Implementers MAY define their own Event Types which MUST be named using a reverse domain name (e.g. "com.example.broker.queueDeleted") for a domain name owned by the implementer." Leave it up to implementers to choose naming conventions and include entityType or other optional attributes in their events. That is better, thanks! > > <[email protected]> wrote on 11/02/2015 22:54:54: > > > From: Alan Conway <[email protected]> > > To: [email protected], > > Date: 11/02/2015 22:55 > > Subject: [amqp] [management] Proposal for event > > notifications (initial outline) > > Sent by: <[email protected]> > > > > > > This is a quick sketch of a design for management event > > notification. I > > wanted to get feedback before getting more formal. I will > > probably be > > implementing something like this in the near future which > > will further > > inform the discussion. > > > > > > Goal: Allow clients to subscribe for notification of > > selected management > > events. > > > > Justification: Polling (with READ or QUERY) for changes inmanagement > > state is inefficient. Either the clients poll too often, > > which overloads > > the management agent, or too seldom which causes delays in > > the system. > > > > DESIGN: > > > > Events are sets of named attributes, like entities. An > > event type name > > MAY begin with an entity type name to indicate the event > > is associated > > with that entity type or it MAY be independent. > > > > All event types MUST have an "eventType" attribute that carries the > > event type name. An implementation defines additional attributes for > > each event type. > > > > A notification message contains a single event. The > > message subject MUST > > be the event type name. The application-properties MUST > > include all the > > event attributes including "eventType". > > > > To subscribe for events, a client creates a link from the address > > "$management.events" with a filter describing the > > notification messages > > that it wants. Closing the link ends the subscription. > > > > The filtering capabilities will depend on the filters > > provided by the > > agent. An agent SHOULD provide the APACHE.ORG:SELECTOR described in > > < http://www.amqp.org/specification/1.0/filters >. This > > allows clients to > > filter on arbitrary SQL-like expressions over all the > > attributes of the > > event including "eventType". > > > > The event type is also in the message subject, so the legacy filters > > described in < http://www.amqp.org/specification/1.0/filters > > > MAY also be > > used to filter by event type. > > > > NOTES: > > > > This design does not allow multiple events to be batched in a single > > message. IMO an implementation should batch messages at > > the transport > > (into TCP packets) NOT batch events into a message. > > Batching in messages > > complicates the client, defeats transport level batching (by forcing > > "fat" messages on the transport) and rules out (or badly > > complicates) > > the use of AMQP filters to select events. > > > > I considered an alternative design where the client sends > > a subscription > > request with a reply-to address and the agent then sends > > notification > > messages to the reply-to address. > > > > I rejected that design for the following reasons: > > > > 1. It is impossible in general to tell when such a > > subscriber goes away > > if it crashes or fails to send an explicit unsubscribe message. > > Implementations must already deal with closing links when clients > > disconnect or heartbeat out so using links solves this > > problem. Even in > > indirect topologies (like link-routed Qpid dispatch networks) the > > routers must proxy link closure to be AMQP-correct. > > > > 2. We should use AMQP standard features to solve AMQP problems, not > > re-invent the wheel in a form only useful for management. > > Filters/selectors were designed for exactly this purpose > > we should make > > them work for us. > > > > Feedback much appreciated!! > > > > Alan. > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe from this mail list, you must leave the > > OASIS TC that > > generates this mail. Follow this link to all your TCs in OASIS at: > > https://www.oasis-open.org/apps/org/workgroup/portal/ > > my_workgroups.php > > > > > ---------------------------------------------------------------------------- > > Deutsche Börse Services s.r.o. > Managing Directors/Geschäftsführung: > Michael Gassmann, Mats Andersson. > Limited liability company with registered office at > Sokolovská 662/136B, CZ-186 00 Prague 8 > recorded in the Commercial Register IC: 275 77 015. > Maintained by the city court in Prague, > Sec. C, File No. 116874. > > ----------------------------------------- > Diese E-Mail enthaelt vertrauliche oder rechtlich geschuetzte Informationen. > Wenn Sie nicht der beabsichtigte Empfaenger sind, informieren Sie bitte > sofort den Absender und loeschen Sie diese E-Mail. Das unbefugte Kopieren > dieser E-Mail oder die unbefugte Weitergabe der enthaltenen Informationen > ist nicht gestattet. > > The information contained in this message is confidential or protected by > law. If you are not the intended recipient, please contact the sender and > delete this message. Any unauthorised copying of this message or > unauthorised distribution of the information contained herein is prohibited. > > Legally required information for business correspondence/ > Gesetzliche Pflichtangaben fuer Geschaeftskorrespondenz: > http://deutsche-boerse.com/letterhead > > > --------------------------------------------------------------------- > To unsubscribe from this mail list, you must leave the OASIS TC that > generates this mail. Follow this link to all your TCs in OASIS at: > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php >