Awesome. We are on the same page then. I think this plugin now is just a matter to be implemented.
For notifications please open issues for any improvements you see (like tracking producers even thought not every protocol will have it) I will close the year with a Discuss thread about the encoding and buffer thing. Will send my holiday wishes once I open that thread. :) On Wed, Dec 21, 2016 at 8:41 AM Christopher Shannon < [email protected]> wrote: > 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 ... > > > > >
