activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matt Pavlovich <>
Subject Re: [DISCUSS] Artemis plugins ARTEMIS-898
Date Wed, 21 Dec 2016 15:08:10 GMT

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 <
>> 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 <>
>> wrote:
>>> On 12/20/16 4:14 PM, Clebert Suconic wrote:
>>>> On Tue, Dec 20, 2016 at 4:42 PM, Matt Pavlovich <>
>>>> 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
>>>>> 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:
>>>> 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 ...

View raw message