I should also add that we don't need to make it one global API or interface like 5.x Maybe it's split up into multiple APIs or plugin types. You could have some sort of plugin to customize connection handling, or a plugin to do message transformation, customizing message dispatch, etc. Some of this probably already exists but that's the idea, just a way to customize behavior. I'm also willing to help out with the PRs to add this functionality.
On Wed, Dec 21, 2016 at 7:13 AM, Christopher Shannon < [email protected]> wrote: > Advisories are extremely useful and being able to monitor events in > detail makes it possible to detect anomalies and to solve issues > quickly. You can do a lot of cool things like process those events > with a CEP engine (like drools) to keep track of the health of a > broker. If the notification API can be used then that is great, in > fact I made mention of that API in my Jira. At the end of the day the > implementation details don't need to be the same as long as long as > the functionality is similar. IE, using notifications instead of > advisories or using JMS 2.0 shared subscriptions instead of Virtual > Topics. Not all features will be moved or have equivalents of course > (there's a ton of bloat in 5.x) but I think that if there's useful > stuff that have valid use cases we should try and support it. > > Getting back on track, a plugin API is very high on my list as a > useful feature and I use it extensively in 5.x. Notifications are > async/callbacks and can be done out of band but having some way to > introduce new behavior "in band" or synchronous is also important. > Take for example the following use cases: > > 1) A user has a requirement to restrict the names of a destination to > a subset of characters > 2) A user wants to add in custom complex security (maybe they want to > block certain users from creating a producer) > 3) A user wants to do some sort of special auditing or logging > 4) A user wants to send custom messages/events when things happen > > The point is that there are any number of use cases that someone might > have or requirements that they need to implement to make the broker > work for them. Instead of trying to solve everyone's use case in my > opinion it's a good idea to make it extensible so people can add in > their own functionality. Many organizations have strict requirements > and rules that need to be followed so there is going to be a > requirement to customize the behavior. > > P.S. removing GC for message memory and maybe using an reusable > off-heap buffer sounds like an awesome idea > > On Tue, Dec 20, 2016 at 5:29 PM, Matt Pavlovich <[email protected]> > wrote: > > On 12/20/16 4:14 PM, Clebert Suconic wrote: > > > >> On Tue, Dec 20, 2016 at 4:42 PM, Matt Pavlovich <[email protected]> > >> wrote: > >>> > >>> I'm not trying to focus on the impl. My goal was to share how users are > >>> able > >>> to > >> > >> ...configure advisories based on a group of destinations.... > >> > >> > >> That to me is very, very specific to ActiveMQ5.... > >> I am not sure you really need that on Artemis, do you? > > > > Yep, its useful. IBM MQ can do the same on a per-destination basis. The > > benefit ActiveMQ 5.x has over IBM MQ is that you can apply a > configuration > > based on a destination filter vs having to configure each queue > > individually. > > > >> and that there is a > >>> > >>> gap in Artemis from a functionality perspective. > >>> > >>> Three different things: > >>> > >>> 1. The gap of specific Advisories/Notifications in Artemis v ActiveMQ 5 > >>> > >>> 2. How Advisories/Notifications are implemented in Artemis plugin vs > core > >>> feature. > >>> > >>> 3. How Advisories/Notifications are configured in Artemis > >> > >> That will be a different API, but that's totally possible to receive > >> notifications: > >> > >> http://activemq.apache.org/artemis/docs/1.5.1/management.html > >> > >> Instead of bringing a new API (Advisory) we could/should look at what > >> notifications are missing and implement them. > > > > Yeah, I'm not married to a specific implementation. This management > > notification piece is new info to me. I was under the impression that > > Advisories of some sort (notifications in Artemis) were at 0% > implemented. I > > need to dig into this some more. > > > >> There are a lot of cool *totally* new things I think we should/could > >> work on. for instance I'm trying to improve / fix message encoding > >> between different protocols (only re-encode a message when needed), > >> and making GC closer to zero by always reusing buffers... That will be > >> a killing feature... I'm not posting a DISCUSS about that yet as I'm > >> still battling over the code and how I am going to work on that. I > >> will post about it after my holiday's break. > > > > +10000 eliminating memory copy of payload is super valuable > > > > I didn't mean to sidetrack the Plugins discussion to > Advisory/Notification.. > > now back to the plugins discussion ... >
