[
https://issues.apache.org/jira/browse/DISPATCH-185?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14969157#comment-14969157
]
Alan Conway commented on DISPATCH-185:
--------------------------------------
Thanks Chuck.
The doc is still a discussion doc on the AMQP WG list, not yet in the official
management draft. Will definitely clean up side comments before that.
DoS - I think we agree, basically there's not much you can do about it in the
notification spec so this proposal doesn't try. Access controls are important
but out of scope here. The only effective defense against accidental
"trace+:everything" is rate limits that close connections/links that go over
quota. However I think this should be part of a separate access control spec
because it would be useful for things other than management notifications.
Custom-alerts: what I was getting at is that a) this can be solved on the
client side and b) it's not trivial so probably something you would want to
encapsulate in a library. Probably not that clear. The real question is who
should keep the state? If it is overall simpler and not less efficient to keep
it on the client, then I think providing client libraries is a good solution
rather than pushing even more complexity, state and processing into the agent.
Notifications have to work well in peer-peer and routed scenarios, so we should
avoid the assumption that an agent is a "kitchen-sink" broker with unlimited
storage and processing capacity compared to its clients.
Thanks for the comments I'll work them into the next draft.
> Support for management notifications, log messages as notifications
> -------------------------------------------------------------------
>
> Key: DISPATCH-185
> URL: https://issues.apache.org/jira/browse/DISPATCH-185
> Project: Qpid Dispatch
> Issue Type: New Feature
> Components: Management Agent
> Affects Versions: 0.5
> Reporter: Alan Conway
> Assignee: Alan Conway
> Fix For: 0.6
>
> Attachments: management-events.rst
>
>
> Implement management notifications along the lines of discussion by the AMQP
> management working group (draft attached)
> As a first test, allow a management client to subscribe for logging events.
> Each client subscription should be able to set its own configuration for the
> logging modules and levels that it wishes to receive, independently of the
> global logging configuration.
> The subscription mechanism should be general (as described in attached draft)
> rather than specific to logging. Other notification event types will be added
> in future.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
