activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Clebert Suconic <clebert.suco...@gmail.com>
Subject Re: [DISCUSS] Artemis plugins ARTEMIS-898
Date Wed, 21 Dec 2016 17:34:21 GMT
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
<christopher.l.shannon@gmail.com> 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 <clebert.suconic@gmail.com
>> 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 <mattrpav@gmail.com>
>> 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 <
>> >> christopher.l.shannon@gmail.com> 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 <mattrpav@gmail.com>
>> >>> wrote:
>> >>>>
>> >>>> On 12/20/16 4:14 PM, Clebert Suconic wrote:
>> >>>>
>> >>>>> On Tue, Dec 20, 2016 at 4:42 PM, Matt Pavlovich <mattrpav@gmail.com>
>> >>>>> 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

Mime
View raw message