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 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
My comments were meant to be an echo of Christopher Shannon's comment
that implementing Advisories/Notifications as a plugin in Artemis would
allow for encapsulation, which would be handy for users/admins.
-Matt Pavlovich
On 12/20/16 3:23 PM, Clebert Suconic wrote:
Notification are also sent over topics... (they are actually sent over
Addresses, so it could be anything).
You're getting too hung on the implementation details.. why it has to
be this specific interface?
From what I looked, the advisory API is a natural mirror of the
broker's implementation.. it fits well with AMQ5, while it will be
some work to be implemented in Artemis.
Feel free to prove me wrong.. but I would use the time into some more
compelling feature. While we battle over specific implementations...
you lose space for other servers that don't even care about the
broker's battle.
On Tue, Dec 20, 2016 at 4:14 PM, Matt Pavlovich <[email protected]> wrote:
Clebert-
That is a good start on the advisories. However, the real world use cases
get complicated when there is mixed configuration based on destination
names. Take the case when you need to haven different behavior for sets of
destinations queue://Billing.> vs queue://Ordering.>.
advisoryForConsumed, advisoryForDelivery, advisoryForFastProducers,
advisoryForSlowConsumers, advisoryWhenFull
Ref: http://activemq.apache.org/per-destination-policies.html
Also, given that advisories are currently sent over topics, there are a
number of use cases where you can almost never get the advisory (broker
becomes master, etc) b/c of the race condition b/w the advisory and having
to have an active topic subscriber. IIRC ActiveMQ doesn't support creating a
durable subscription for advisories, which would help those scenarios.
It'd be handy to support Advisory notification as a plugin, so we could
build advisory-to-log plugin, advisory-over-topic plugin, advisory-to-XX
plugin, etc.
-Matt Pavlovich
On 12/20/16 2:08 PM, Clebert Suconic wrote:
Artemis already has the notification listener in place:
These are the notification currently supported:
https://github.com/apache/activemq-artemis/blob/master/artemis-core-client/src/main/java/org/apache/activemq/artemis/api/core/management/CoreNotificationType.java
There are a few more that still didn't merge the core model yet:
https://github.com/apache/activemq-artemis/blob/master/artemis-jms-server/src/main/java/org/apache/activemq/artemis/jms/server/management/JMSNotificationType.java
On Tue, Dec 20, 2016 at 2:43 PM, Christopher Shannon
<[email protected]> wrote:
A plugin API is actually one of the big things on my list as well. In
5.x it is very easy to add extra functionality at certain points in
the chain (on a new connection, new consumer, etc) and I think having
some mechanism to do that in Artemis will be useful as well. I use a
combination of plugins that come out of the box with 5.x as well as
custom ones that are specific to my use case.
I opened up https://issues.apache.org/jira/browse/ARTEMIS-796 for
Advisory support and it might be a good candidate as a plugin as Matt
pointed out.
On Tue, Dec 20, 2016 at 11:54 AM, Clebert Suconic
<[email protected]> wrote:
The inbound would transform the message before it enters the broker.
Outbound would only apply to the current delivery.
It would be a nice feature.
On Tue, Dec 20, 2016 at 11:44 AM Matt Pavlovich <[email protected]>
wrote:
Clebert-
I think outbound/inbound separation would be really handy for plugin
writers. Are these statements correct based on what you are thinking w/
inbound and outbound?
1. The outboundTransformer() would transform messages for one or more
client consumer(s) and across protocols. ie.. one JMS consumer, one
STOMP consumer on the same address would receive the transformed copy
of
the message.
2. The outboundTransformer would _not_ transformation messages being
sent to other brokers (replication and/or pub+sub to brokers in a
cluster)
3. For the inboundTransformer.. the message would be transformed for
all
delivery into the broker for all consumers, brokers and diverts.
Thanks,
Matt
On 12/20/16 10:33 AM, Clebert Suconic wrote:
I think we should include two options on AddressSettings:
i - inboundTransformer
ii - maybe an outboundTransformer
inboundTransformer (String address, ServerSession session,
ServerMessage message);
outboundTransformer(String address, ServerSession session,
ServerMessage message);
The trick part here is that outboundTransformer would need to work on
a copy of the message. so, the API needs to return a copy of the
message.
I am working now on refactoring encoding and transformer between
protocols that would make this a bit easier. I'm at the design phase
and I will post a DISCUSS thread about that when I have something more
concrete to talk about it.
On Tue, Dec 20, 2016 at 11:22 AM, Matt Pavlovich <[email protected]>
wrote:
I was taking a first step in implementing an existing ActiveMQ 5.x
plugin in
the Artemis source and noticed that there is a gap in the
availability
of
extension points in Artemis (or plugins).
I opened ARTEMIS-898 for tracking, and thought it deserved a
discussion.
This feels like a good target as a 2.x feature, since it would most
likely
be API changing. It stands to reason the extension points in Artemis
would
be very different than ActiveMQ 5.x, so I've laid it out in terms of
features and capabilities.
The big three:
1. Message header / property manipulation. Allows admins to set
message
policies for things like JMSXUserId, Timestamps, Expiry, etc
2. Message body manipulation. (Clebert mentioned perhaps an extension
of
Divert / Transformers?)
3. Activity tracing for audit tracing and/or triggering other
activity
(extension point at PostOffice and ActiveMQServer ?)
One side benefit might be that Advisory support becomes a plugin vs
an
ingrained feature. Could be handy to have all the advisory logic in
one
place to allow more customization of behavior.
Thoughts?
-Matt Pavlovich
