activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martyn Taylor <>
Subject Re: [DISCUSS] Artemis addressing improvements, JMS component removal and potential 2.0.0
Date Fri, 18 Nov 2016 11:44:24 GMT

This can work.  If you look at the ARTEMIS-780 branch and see how we've
approached this, you'll notice that we don't touch any of the internal
APIs.  It's only a few methods added.  Having two addresses in the config,
is not really creating two addressing inside of Artemis.  There's only one
address and all queues have this address.  The only thing that changes is
the fact that a queue binding now has some meta-data (an AddressInfo
object) that determines how messages are routed to it.  It's perfectly
viable to have 2 queues, with the same address, but with different address
info objects.

As for the producer case, we could just add a message header that
identifies that this was sent for addresses with "multicast" only.  And put
the appropriate filter on the queues when they're created.

In summary, it's possible, the question is whether this is the correct
approach.  I'm open to ideas, but I don't think anyone has suggested
anything as of yet that covers all use cases.


On Thu, Nov 17, 2016 at 12:28 PM, Clebert Suconic <
> wrote:

> > Just so I understand exactly what you are saying here.  You're saying
> that
> > a client sends to "foo" and a consumer received messages sent to "foo".
> In
> > order for the consumer to consume from "foo" it passes in either "foo",
> > "queue:///foo" or "topic:///foo" which determines how the messages are
> > propagated to the client?  "foo" means let the broker decide,
> > "queue:///foo" and "topic:///foo" mean let the client decide.  In
> addition
> > to these two approaches, it may be that the protocol itself wants to
> > decide.  MQTT for example, always requires a subscription.
> >
> > One way to do this, not straying too far from the original proposal,
> would
> > be to make the address uniqueness a combination of the routing type and
> the
> > address name.  This would allow something like:
> >
> > <address name="foo" routingType="anycast">
> > <address name="foo" routingType="multicast">
> >
> > We'd need to ensure there is a precedent set for times when a subscriber
> > just subscribes to "foo".  I'd say it makes sense for "multicast" to take
> > precedence in this case.
> That wouldn't work. You would need to change the API to pass in an
> address type, the protocols to have an address type (in a way it
> wouldn't be compatible with previous clients).
> I think this is settled if you make the prefix configurable for cases
> where users want to have such thing.

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message