activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matt Pavlovich <mattr...@gmail.com>
Subject Re: [DISCUSS] Artemis plugins ARTEMIS-898
Date Tue, 20 Dec 2016 21:08:24 GMT
+1 Having the Advisory Notification as a plugin would allow a way for 
admins to configure behavior, or completely do a full re-implementation 
as needed.

 From a functional perspective perhaps it would help to split the use cases:

1. Message handling plugin(s)  (recv message / send message, manipulate 
headers-- timestamp, expiry, etc)

2. Broker object life cycle (queue created, consumer added, broker added 
to cluster, broker-becomes-master, etc)
     --> Advisory plugin could live here

3. Destination Policies Behaviors (subscription retention policies, 
etc.. last message, last # messages, last messages for X period of 
time). Destination Garbage Collection

Would these need to be separate extension points In Artemis?

On 12/20/16 1:43 PM, Christopher Shannon 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
>>>
>>>
>>>


Mime
View raw message