jbertram noted some misuse of "destination" terminology. Updated notes
(hopefully mostly correct):
http://pastebin.com/gumnStwq
On 11/18/16 11:57 AM, Matt Pavlovich wrote:
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.
ref: http://pastebin.com/0WaMT8Yx
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
Questions:
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?
Discussions:
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 <[email protected]>
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.
