activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matt Pavlovich <>
Subject Re: [DISCUSS] Artemis addressing improvements, JMS component removal and potential 2.0.0
Date Fri, 18 Nov 2016 16:57:02 GMT
Good call, sounds like a plan. Here is the link and a copy of the latest 
set of my notes trying to do the same.


Addressing Behavior Use Cases [Draft]
1. Destination addresses will be stored in canonical form without prefixes
     ie.  queue:///foo will be stored as name=“foo” type=“anycast”
           topic://bar will be stored as name=“bar” type=“multicast”

2. Destinations must specify a type in the configuration

3. Destinations may be auto-created when the intersection of protocol 
support, broker-side configuration and user permissions permits

4. [JMS] session.createQueue(“foo”) must be translated to the fully 
qualified name of “queue:///foo” in the client provider library (or some 
internal core protocol/api equiv)

5. [JMS] session.createQueue(“queue:///foo”) and 
session.createQueue(“queue://foo”) and session.createQueue(“foo”) refer 
to the same destination

6. [STOMP and AMQP] will default to “anycast” address type (configurable 
at broker transport?) during lookup and throw an exception if there is a 
name collision when using unqualified destination name.
     ie. User specifies “blah” and both types exist

7. [MQTT] will default to topic name unless fully qualified to use the 
queue address (needs research.. MQTT may not allow URI format in 
destination name)

8. [STOMP, AMQP and other protocols] will support appropriate prefix 
mapping to their destination name format.  For example: /queue/foo and 
/topic/foo will be translated to foo  type=“any cast” and foo  
type=“multicast” internally


Q-0: Does Artemis support the separation of queue-like and topic-like 
addresses?  ie.. foo type=“anycast” and foo type=“multicast” can 
co-exist and are distinct addresses. (Not currently the behavior)

Q-1: What destination type should be created by default for STOMP, AMPQ 
and MQTT unqualified addresses?

Q-2: What destination type should be looked up by default for STOMP, 
AMPQ and MQTT of unqualified addresses?

Q-3: How would queue://$broker/$host fully qualified destinations names 
be supported in STOMP, AMQP and MQTT?


D-1: jbertram would like to table support for Q-3 fully qualified names 
(host+destination) until after ARTEMIS-780 is done. The reasoning is to 
keep things simple and avoid uncertain future complexity.

D-2: mattrpav recommends planning for fully qualified names before 2.0 
is released (doesn’t need to be part of 780) in order in order to avoid 
any impacts post-2.0. The reasoning is that in order for Artemis to 
compete as a replacement with majority of EMS products (IBM MQ, Tibco 
EMS, etc) host+destination routing is a must-have.

On 11/18/16 11:29 AM, Martyn Taylor wrote:
> All,
> I think we need to take a step back here and try to capture all the use
> cases discussed thus far, we've had a few use cases outlined here and
> plenty of discussion @ #apache-activemq channel.  I think it's difficult to
> discuss solutions until everyone is on the same page when it comes to the
> requirements.
> I'll start pulling this together, and reply here once I am done.
> Thanks for all the input so far.
> On Fri, Nov 18, 2016 at 4:00 PM, Matt Pavlovich <> wrote:
>>    No. What I am thinking is that all addresses are prefixless. What you are
>>> really saying when you say “queue://foo” is not that I want to
>>> send/consume
>>> to/from an address “queue://foo” but that you want to send/consume to/from
>>> an address named “foo” and that you expect queue semantics on that
>>> address.
>>> If you don’t specify semantics with the address name. For example, let’s
>>> say in MQTT you send to “foo”. This message would be sent to 1 consumer
>>> that have specified “queue://foo” and all consumers that specified
>>> “topic://foo”. As far as Artemis is concerned the address is just "foo".
>>> The prefixes are added in the clients, and used by the protocol managers
>>> to
>>> ask Artemis for certain behaviours.
>> How do you see this use case working out? If a JMS client sends a message
>> to session.createQueue("foo") and Artemis auto-creates a "foo"
>> type="anycast". Then two MQTT clients (MQTT being topic-based) come around
>> a subscribe to "foo" do the MQTT clients round-robin the data or each get a
>> copy of the message?.
> Can we shelve this for now and pick it up once we have outlined all the use
> cases.

View raw message