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

[Jakub.Scholz@deutsche-boerse.com]

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?

Thanks & Regards
Jakub

<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