Matt, that sounds like a good start to me with the plugins. Camel is another good feature from 5.x which would be good to have in Artemis.
On Wed, Dec 21, 2016 at 12:20 PM, Clebert Suconic <[email protected] > wrote: > I guess this is an old JIRA: > > https://issues.apache.org/jira/browse/ARTEMIS-17 Add Broker > Interceptor - like the Camel Broker Component in ActiveMQ 5 > > On Wed, Dec 21, 2016 at 10:08 AM, Matt Pavlovich <[email protected]> > wrote: > > Christopher- > > > > I agree.. what are your thoughts on this breakout of plugin types: > > > > 0. Interceptors: protocol-level plugins (already exist) > > > > 1. Message handling plugin(s) (recv message / send message, manipulate > > headers-- timestamp, expiry, etc) > > --> Re-use Artemis "Transformer" > > > > 2. Broker object life cycle (queue created, consumer added, broker added > to > > cluster, broker-becomes-master, etc) > > > > 3. "ActiveMQ 5.x Destination Policies" Behaviors (message dispatch, > > subscription retention policies, etc.. last message, last # messages, > last > > messages for X period of time). Destination Garbage Collection > > > > > > -Matt Pavlovich > > > > > > On 12/21/16 7:40 AM, Christopher Shannon 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 ... > > > > > > > > -- > Clebert Suconic >
