activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Shannon <christopher.l.shan...@gmail.com>
Subject Re: [DISCUSS] Artemis plugins ARTEMIS-898
Date Wed, 21 Dec 2016 12:13:04 GMT
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 ...

Mime
View raw message