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