Re: [amqp] [management] Proposal for event notifications (initial outline)

[Alan Conway <aconway@redhat.com>]

On Fri, 2015-02-13 at 10:26 +0100, Jakub.Scholz@deutsche-boerse.com
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!

> 
> <amqp@lists.oasis-open.org> wrote on 11/02/2015 22:54:54:
> 
> > From: Alan Conway <aconway@redhat.com>
> > To: amqp@lists.oasis-open.org,
> > Date: 11/02/2015 22:55
> > Subject: [amqp] [management] Proposal for event
> > notifications (initial outline)
> > Sent by: <amqp@lists.oasis-open.org>
> >
> >
> > 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 
>