I have talked to some guys from Camel. I believe they wanted to have whatever feature is needed for Camel living in Camel, as opposed to what we have now.
But the broker interceptor is sure on the list... I guess ARTEMIS-17 would make ARTEMIS-898 a duplicate. we will have to ellect one of the two to be closed as duplicate. On Wed, Dec 21, 2016 at 12:31 PM, Christopher Shannon <[email protected]> wrote: > 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 >> -- Clebert Suconic
