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:20:08 GMT
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

Mime
View raw message