Mailing-List: contact dev-help@activemq.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@activemq.apache.org
MIME-Version: 1.0
In-Reply-To: <CAKF+bsq4oEMYE_X5imBYc_sLGsGtT59spe99sqvZeQB+YLzoKw@mail.gmail.com>
References: <2c22bee4-5d67-c764-fe6b-4a5cd2e14999@gmail.com>
 <CAKF+bsrKYUUbn-yQNiNNxE4uizuo9Wq8JYaPFueNDEeXANk_PQ@mail.gmail.com>
 <166f2ace-e11c-2cba-21ff-feeebb775057@gmail.com> <CAKF+bsq=jDwKc0w8YHdc5-sZk2stf9fG4ij-FSBeBJ9aetGTwg@mail.gmail.com>
 <CACHnxzz+Gwfxok4+WP1O9CzCcT-+wmP7AZrd_92ZupjydR4A+A@mail.gmail.com>
 <CAKF+bspey_EVhyr4s3HzRGkkXT9n=ar94Z7vj89QXPD=eSy0_A@mail.gmail.com>
 <ba47ca23-c2b2-887b-99d9-4e57c14e9351@gmail.com> <CAKF+bspVZDvEiH0cqLROGAiLQPQzin2RXr5EJZgGZGfMiGT9Vg@mail.gmail.com>
 <fbb013f4-8229-d1ca-f56e-4865e13b5c21@gmail.com> <CAKF+bsoyW96Xotqogn4ethXJ+gaKwpszg=FuMFbYgR0j8cno1Q@mail.gmail.com>
 <b9907456-2dea-3806-c155-a42bdbfd8874@gmail.com> <CACHnxzy0jpJ+pWoMBZzD5EL0gJjV6iiOuoZZJuj62P-wX24ymA@mail.gmail.com>
 <CACHnxzyzibrWAP-1=_5TC4K1V1_vUVuk2M7aGRrU3raCwGK0Dw@mail.gmail.com>
 <364c0ee7-c40a-2a57-bab1-9b6ff0916d80@gmail.com> <CAKF+bsq4oEMYE_X5imBYc_sLGsGtT59spe99sqvZeQB+YLzoKw@mail.gmail.com>
From: Christopher Shannon <christopher.l.shannon@gmail.com>
Date: Wed, 21 Dec 2016 12:31:59 -0500
Message-ID: <CACHnxzwQNek1Mjxk6AXBer7g6y628He2kHiv+mZXr6X5nFkggA@mail.gmail.com>
Subject: Re: [DISCUSS] Artemis plugins ARTEMIS-898
To: dev@activemq.apache.org
Content-Type: multipart/alternative; boundary=001a114c8760896deb05442e8954
archived-at: Wed, 21 Dec 2016 17:32:36 -0000

--001a114c8760896deb05442e8954
Content-Type: text/plain; charset=UTF-8

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
>

--001a114c8760896deb05442e8954--