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 Tue, 20 Dec 2016 20:16:36 GMT
IMHO We should look at the usecase instead of the implementation.
Instead of bringing Advisory Support, look what you can't do with the
current notification and expand from there.


Copying functionality from activemq just by itself might be an
unsolvable battle. It's a different codebase and it might not fit the
code between the two.  But supporting the usecases is totally doable.

usecase is: like providing knowledge when a certain event happened, or
how to intercept messages at the broker level.

Implementation would be: support the exact same API as the Advisory
Support... it might be a forever battle.


I'm not talking about any specific point here.. just pointing this for
general cases.


On Tue, Dec 20, 2016 at 3:08 PM, Clebert Suconic
<clebert.suconic@gmail.com> 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
> <christopher.l.shannon@gmail.com> 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
>> <clebert.suconic@gmail.com> 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 <mattrpav@gmail.com> 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 <mattrpav@gmail.com>
>>>> 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
>>>>
>>>> >>
>>>>
>>>> >>
>>>>
>>>> >
>>>>
>>>> >
>>>>
>>>>
>>>>
>>>>
>
>
>
> --
> Clebert Suconic



-- 
Clebert Suconic

Mime
View raw message