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
