Your use-case sounds exactly like what's called "shared subscriptions" in
JMS 2. Using this feature many applications can all receive the same set of
messages (i.e. your "normal" listeners) but a handful of applications can
_share_ the messages on a single subscription (i.e. your "distributed"
listeners). Are you using JMS in your application?

Or are you possibly using MQTT? This same kind of feature was added in MQTT
5.

There are some caveats here based on what protocol you're using, but
generally speaking you can also specify this kind of configuration in
broker.xml, e.g.:

   <addresses>
      ...
      <address name="myTopic>
         <multicast/>
         <anycast>
            <queue name="myQueue"/>
         </anycast>
      </address>
      ...
   </addresses>

Messages sent to myTopic will be routed to all the multicast queues (e.g.
subscription queues created at runtime on behalf of remote applications) as
well as the single anycast queue "myQueue." Then you can have multiple
applications share the messages in "myQueue" via the
fully-qualified-queue-name (i.e. "myTopic::myQueue").

Without more details about your use-case I can't provide specific
recommendations, but I think you can fulfill your use-case without a
divert/transformer combo. Of course, this also means that most other folks
can do the same which means your transformer is not likely to be accepted
into the code-base.


Justin

On Tue, Jun 11, 2024 at 8:18 AM <maximilian.rie...@systema.com> wrote:

> So our use-case can be described as the following:
> For example there are messages on the topic Test.topic and we listen on
> them in a classic publish subscribe manner.
> But we also want to be able to set up distributed listeners, so that they
> consume the messages sent on this topic as if it was in a queue.
> So e.g. we have three "normal" listeners and three distributed listeners
> on this topic.
> When a message is sent, the normal listeners each receive the message but
> as for the distributed listeners just one receives the message.
> Thats why we use the transformer with the divert to move the messages on
> the topic also in a queue with a prefix.
> I hope it is understandable what i mean.
>
> best regards
> Maximilian
>
>
>
> Von:        "Justin Bertram" <jbert...@apache.org>
> An:        dev@activemq.apache.org
> Datum:        06/07/2024 10:35 PM
> Betreff:        [Ext] Re: Re: PrefixAddressTransformer for unique event
> divert
> ------------------------------
>
>
>
> Can you share more about your use-case? It may actually be covered by the
> core address model of ActiveMQ Artemis [1].
>
> You can actually have a JMS queue and a JMS topic with the same name,
> although it's typically not recommended because it can be very confusing.
>
>
> Justin
>
> [1]
>
> https://activemq.apache.org/components/artemis/documentation/latest/address-model.html#address-model
>
> On Fri, Jun 7, 2024 at 10:50 AM <maximilian.rie...@systema.com> wrote:
>
> > Hello,
> >
> > First of all, thanks for the reply. Im sorry if the explanation was a
> > little imprecise.
> > Yes you are correct. We use it so we can consume messages on a topic, but
> > also in a queue.
> > The prefix is used, because the queue and the topic cant share the same
> > name if i am correct.
> > Similar to ActiveMQ, where we are using a virtualDestinationInterceptor
> to
> > redirect Event messages into a queue to be consumed by distributed
> > applications.
> >
> > Max
> >
> >
> >
> > Von:        "Arthur Naseef" <artnas...@apache.org>
> > An:        dev@activemq.apache.org
> > Datum:        06/06/2024 06:20 PM
> > Betreff:        [Ext] Re: PrefixAddressTransformer for unique event
> divert
> > ------------------------------
> >
> >
> >
> > If I read it correctly, the transformer together with the divert
> provides a
> > means to duplicate messages from any number of inbound destinations to a
> > parallel set of destinations by adding a prefix.
> >
> > For example:
> >
> > test.events.a.1  -> TestQ.test.events.a.1
> >
> > test.events.b.2 -> TestQ.test.events.b.2
> >
> > Like a wiretap, using parallel queue structures.
> >
> > Did I get that right?
> >
> > Art
> >
> >
> > On Thu, Jun 6, 2024 at 8:55 AM Justin Bertram <jbert...@apache.org>
> wrote:
> >
> > > Generally speaking, _every_ commit which fixes a bug or adds a feature
> or
> > > improvement should have a test. This ensures the bug is actually fixed
> or
> > > the feature actually works and also mitigates regressions later.
> > >
> > > Furthermore, if you want this to be something accessible to end-users
> > then
> > > documentation should be part of the commit as well (e.g. here [1]).
> > >
> > > All that said, however, I'm not sure the use-case for this transformer
> is
> > > general enough to be shipped with the broker. I can't really tell what
> > the
> > > use-case is based on your email.
> > >
> > > Of course, feel free to send a PR with tests and documentation and then
> > it
> > > can be properly evaluated.
> > >
> > >
> > > Justin
> > >
> > > [1]
> > >
> > >
> >
> https://github.com/apache/activemq-artemis/blob/main/docs/user-manual/transformers.adoc
> > >
> > > On Thu, Jun 6, 2024 at 7:24 AM <maximilian.rie...@systema.com> wrote:
> > >
> > > > Hello,
> > > >
> > > > we are currently using a Transformer to redirect Event messages into
> a
> > > > queue to consume them as kind of Unique Processing by distributed
> > > > applications.
> > > > For this we use a transformer:
> > > >
> > > > public class PrefixAddressTransformer implements Transformer
> > > > {
> > > >    @Override
> > > >    public Message transform(Message message)
> > > >    {
> > > >       SimpleString originalAddress =
> > > >
> > > (SimpleString)message.getBrokerProperty(Message.HDR_ORIGINAL_ADDRESS);
> > > >       message.setAddress(message.getAddress() + "."
> > > > +originalAddress.toString());
> > > >       return message;
> > > >    }
> > > > }
> > > >
> > > > That we use with with a divert:
> > > >
> > > >       <diverts>
> > > >          <divert name="test-events-divert">
> > > >               <address>test.events.#</address>
> > > >               <forwarding-address>TestQ</forwarding-address>
> > > >               <exclusive>true</exclusive>
> > > >
> > > >
> > >
> >
> <transformer-class-name>org.apache.activemq.artemis.core.server.transformer.PrefixAddressTransformer</transformer-class-name>
> > > >          </divert>
> > > >      </diverts>
> > > >
> > > > So that all messages on test.events.# are also sent to a queue
> > > > TestQ.test.events... and can be processed in a distributed manner.
> > > > Others might also profit from this, so we wanted to commit it to the
> > > > offical artemis repo.
> > > >
> > > > Should there be testing done on this transformer, like with the
> > > >
> > >
> >
> org.apache.activemq.artemis.core.server.transformer.AddHeadersTransformer,
> > > > which is tested in
> > > >
> > >
> >
> org.apache.activemq.artemis.tests.integration.management.DivertControlTest
> > > > ?
> > > >
> > > > best regards
> > > > Maximilian Rieder
> > > > ------------------------------
> > > >
> > > > *Maximilian Rieder*
> > > > Software Engineer
> > > >
> > > > Phone: +49 941 / 7 83 92 84
> > > > maximilian.rie...@systema.com
> > > >
> > > > www.systema.com
> > > >
> > > > [image: LinkedIn] <https://www.linkedin.com/company/systema-gmbh/
> > > >[image:
> > > > Facebook] <https://de-de.facebook.com/SYSTEMA.automation/>[image:
> > XING]
> > > > <https://www.xing.com/pages/systemagmbh>
> > > >
> > > > SYSTEMA
> > > > Systementwicklung Dipl.-Inf. Manfred Austen GmbH
> > > >
> > > > Manfred-von-Ardenne-Ring 6 | 01099 Dresden
> > > > HRB 11256 Amtsgericht Dresden | USt.-ID DE 159 607 786
> > > > Geschäftsführer: Manfred Austen, CEO und Dr. Ulf Martin, COO
> > > >
> > > > P Please check whether a printout of this e-mail is really necessary.
> > > >
> > >
> >
> >
> >
> > ------------------------------
> >
> > *Maximilian Rieder*
> > Software Engineer
> >
> > Phone: +49 941 / 7 83 92 84
> > maximilian.rie...@systema.com
> >
> > www.systema.com
> >
> > [image: LinkedIn] <https://www.linkedin.com/company/systema-gmbh/
> >[image:
> > Facebook] <https://de-de.facebook.com/SYSTEMA.automation/>[image: XING]
> > <https://www.xing.com/pages/systemagmbh>
> >
> > SYSTEMA
> > Systementwicklung Dipl.-Inf. Manfred Austen GmbH
> >
> > Manfred-von-Ardenne-Ring 6 | 01099 Dresden
> > HRB 11256 Amtsgericht Dresden | USt.-ID DE 159 607 786
> > Geschäftsführer: Manfred Austen, CEO und Dr. Ulf Martin, COO
> >
> > P Please check whether a printout of this e-mail is really necessary.
> >
>
>
>
> ------------------------------
>
> *Maximilian Rieder*
> Software Engineer
>
> Phone: +49 941 / 7 83 92 84
> maximilian.rie...@systema.com
>
> www.systema.com
>
> [image: LinkedIn] <https://www.linkedin.com/company/systema-gmbh/>[image:
> Facebook] <https://de-de.facebook.com/SYSTEMA.automation/>[image: XING]
> <https://www.xing.com/pages/systemagmbh>
>
> SYSTEMA
> Systementwicklung Dipl.-Inf. Manfred Austen GmbH
>
> Manfred-von-Ardenne-Ring 6 | 01099 Dresden
> HRB 11256 Amtsgericht Dresden | USt.-ID DE 159 607 786
> Geschäftsführer: Manfred Austen, CEO und Dr. Ulf Martin, COO
>
> P Please check whether a printout of this e-mail is really necessary.
>

Reply via email to