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

[Alan Conway <aconway@redhat.com>]

On Mon, 2015-02-16 at 20:09 +0100, Rob Godfrey wrote:
> Wrote this (while on the plane) in reply to the earlier proposal.
> While I've been in the air I see you've put out a revised proposal
> which I shall look at on my next flight...
> 
> > On 13 February 2015 at 19:12, Alan Conway <aconway@redhat.com> wrote:
> >         After some encouraging feedback, here it is again specified
> >         and
> >         simplified (thanks Jakub). I'm still interested in feedback on
> >         the spec
> >         or potential implementation issues. I will probably be
> >         implementing this
> >         or something like it shortly.
> >
> >         Cheers
> >         Alan.
> >
> >         ----
> >         # AMQP Management Event Notification
> >
> >         Management clients often need to know when the state of a
> >         managed entity
> >         has changed.  This can be for monitoring or logging purposes,
> >         or to
> >         react when something becomes ready for use.
> >
> >         Polling the management agent for changes with READ or QUERY
> >         operations
> >         is inefficient. Clients either poll too often, which overloads
> >         the
> >         agent, or too seldom which causes needless delays in the
> >         system.
> >
> >         Event notification allows management clients to subscribe for
> >         continuous
> >         notification of selected events as soon as the agent becomes
> >         aware of
> >         them.
> >
> >         ## Event Types
> >
> >         An Event Type is a named set of attributes. The name is a
> >         case-sensitive
> >         string. Implementers MAY define their own Event Types which
> >         MUST be
> >         named using a reverse domain name prefix owned by the
> >         implementer, e.g.
> >         "com.example.broker.queueDeleted".
> 
> Are event types releative to entity types or not? 

My current feeling is "not by the spec". An implementation is free to
define such a relationship or naming convention. If we feel we are ready
to define the relationship we could revise that.

> As an aside, do events have unique ids or sequence numbers, or timestamps? At
> the very least perhaps we should give names for these attributes even if they
> are not supported by every event type.

Not yet, we could add that. If we allow the user to select attributes
they are interested in then we could include them in every entity type
and the user can select them or not as desired.

> 
> Are you suggsting that every management node have a corresponding ".events"
> node, or that this applies soley to the special case $management?  Is the
> support of events mandatory for every management node?

Probably not mandatory. That's really just a placeholder address
definitley willing to take on suggestions from the addressing spec.

> One thought here is that we should more explicitly define an address/topic
> hierarchy and use wilcard pattern matching.  In the bindmap group Shawn has
> suggested (and we agreed in principle on the core TC call last time) to use
> MQTT-like pattern matching.  This could give us something like <management node
> name>/<event type>/<entity type>/<entity id> where # and + could be used as the
> matching wildcards.  This would allow someone to subscribe for "all delete
> events" or "all events related to queues" or "all events related to queue id X".
> 
> >         The filtering capabilities 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".
> >
> 
> Even if we decide for SQL like filters then we probably want to look at what the
> JMS mapping spec comes up with here, I don't think the Apache filter is quite
> what we want.

According to the Apache page, these *are* JMS selectors: " The Java
Message Service "selector" defines an SQL like syntax for filtering
messages." Is there something new coming in JMS?

My thinking so far is that we use a message filter, any filter, and
recommend the most powerful one but allow use of others in future.
The benefit of selectors over address wildcarding is you can express
things like queueDepth > 10000. I don't see any other way in the AMQP
spec to do that.

Cheers,
Alan.