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 Mon, 21 Nov 2016 16:45:20 GMT

I have read back through this list, the requirements document provided by
Matt, and our conversations on IRC.

>From what I have read it seems there are a few missing pieces of
functionality that we need to address in these addressing changes and at
least one piece of functionality that should be possible to support in the
future, without changes to the model. I’ve tried my best to outline the
requirements and related them to the original proposal. Could those of you
who are interested please ack or comment to ensure I have covered all
scenarios. I’ve also outlined a potential modification to the model that
take these requirements into consideration.

1. Ability to route messages to queues with the same address, but different
routing semantics.

The proposal outlined in ARTEMIS-780 outlines a new model that introduces
an address object at the configuration and management layer. In the
proposal it is not possible to create 2 addresses with different routing
types. This causes a problem with existing clients (JMS, STOMP and for
compatability with other vendors).

Potential Modification: Addresses can have multiple routing type
“endpoints”, either “multicast” only, “anycast” only or both. The example
below would be used to represent a JMS Topic called “foo”, with a single
subscription queue and a JMS Queue called “foo”. N.B. The actual XML is
just an example, there are multiple ways this could be represented that we
can define later.

<*addresses*>   <*address* *name**="foo"*>      <*anycast*>
<*queues*>            <*queue* *name**="**foo”* />         </*queues*>
     </*anycast*>      <*mulcast*>         <*queues*>
<*queue* *name**="my.topic.subscription" */>         </*queues*>
</*multicast*>   </*address*></*addresses*>

2. Sending to “multicast”, “anycast” or “all”

As mentioned earlier JMS (and other clients such as STOMP via prefixing)
allow the producer to identify the type of end point it would like to send

If a JMS client creates a producer and passes in a topic with address
“foo”. Then only the queues associated with the “multicast” section of the
address. A similar thing happens when the JMS producer sends to a “queue”
messages should be distributed amongst the queues associated with the
“anycast” section of the address.

There may also be a case when a producer does not identify the endpoint
type, and simply sends to “foo”. AMQP or MQTT may want to do this. In this
scenario both should happen. All the queues under the multicast section get
a copy of the message, and one queue under the anycast section gets the

Modification: None Needed. Internal APIs would need to be updated to allow
this functionality.

3. Support for prefixes to identify endpoint types

Many clients, ActiveMQ 5.x, STOMP and potential clients from alternate
vendors, identify the endpoint type (in producer and consumer) using a
prefix notation.

e.g. queue:///foo

Which would identify:

<*addresses*>   <*address* *name**="foo"*>      <*anycast*>
<*queues*>            <*queue* *name**="" */>
</*queues*>      </*anycast*>   </*address*></*addresses*>

Modifications Needed: None to the model. An additional parameter to the
acceptors should be added to identify the prefix.

4. Multiple endpoints are defined, but client does not specify “endpoint
routing type” when consuming

Handling cases where consumers does not pass enough information in their
address or via protocol specific mechanisms to identify an endpoint. Let’s
say an AMQP client, requests to subscribe to the address “foo”, but passes
no extra information. In the cases where there are only a single endpoint
type defined, the consumer would associated with that endpoint type.
However, when both endpoint types are defined, the protocol handler does
not know whether to associate this consumer with a queue under the
“anycast” section, or whether to create a new queue under the “multicast”
section. e.g.

Consume: “foo”


   <*address* *name**="foo"*>      <*anycast*>         <*queues*>
      <*queue* *name**="**foo”* />         </*queues*>
</*anycast*>      <*multicast*>         <*queues*>            <*queue*
*name**="my.topic.subscription" */>         </*queues*>
</*multicast*>   </*address*></*addresses*>

In this scenario, we can make the default configurable on the
protocol/acceptor. Possible options for this could be:

“multicast”: Defaults multicast

“anycast”: Defaults to anycast

“error”: Returns an error to the client

Alternatively each protocol handler could handle this in the most sensible
way for that protocol. MQTT might default to “multicast”, STOMP “anycast”,
and AMQP to “error”.

5. Fully qualified address names

This feature allows a client to identify a particular address on a specific
broker in a cluster. This could be achieved by the client using some form
of address as:


Matt could you elaborate on the drivers behind this requirement please.

I am of the opinion that this is out of the scope of the addressing
changes, and is more to do with redirecting in cluster scenarios. The
current model will support this address syntax if we want to use it in the


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