On 11/16/16 2:23 PM, Justin Bertram wrote:
0. Auto-creation for JMS queues and topics was already supported, and I expect
that will continue.
0. isn't about auto-creation per-say, its about allowing protocol
specific handlers to create address objects as needed for things like
subscriptions. JMS durable subscription, MQTT retain, etc.
1. I'm not sure I understand the use-case for having a topic and queue with the
same name. Can you clarify this?
Re-pasting from the IRC convo for folks on the list:
1a. I’m saying 90% of the products in the enterprise messaging market
supports it (IBM MQ, ActiveMQ 5.x, Tibco EMS). The spec does not clearly
call it out specifically. I believe JMS v.1.1 4.11 and 10.1.3 could be
interpreted as support for it.
1b. Since the addressing work is being done now, it seems like a good
time to get a decision on it
1c. NOT supporting it would mean breaking compatibility b/w ActiveMQ 5.x
and having to document it for folks migrating from major commercial JMS
providers
1d. I do not know of a JMS provider that does _not_ support this
2. I expect STOMP to have configurable multicast and anycast prefixes for destinations. Whether
users choose "/topic/" and "/queue/" for those respectively is up to them. I'm
not sure about AMQP.
Makes sense.. IHMO using the same prefix across protocols as much as
possible would be super dope.
3. I think using URIs has merit, but each protocol has nuances that would
probably make something universal impossible.
Which protocol(s)?
4. See ARTEMIS-815 (sub-task of ARTEMIS-780).
Rockin, that covers it! This is something that ActiveMQ 5.x seemed to
not always have consistent (specifically, in some plugins that only
operate on "."). Destination separator probably needs to be a one-time
deal across the broker b/c plugins may need to reference it via global
config object.
5. Can you clarify this a bit more? An example would be great.
Other messaging systems (namely, IBM MQ Remote Queues, Cluster Queues)
support fully qualified destination names.
Example:
a. Client connects to BrokerA.
b. Client sends message addressed as queue://BrokerB/My.Queue
c. BrokerA delivers message to BrokerB on behalf of the client
d. BrokerB delivers the message to queue:///My.Queue
The use case is client code to be able to work with dynamic networks
(think retail environments / kiosk / IoT where remote brokers come up
and down in relative high frequency). A remote broker naming convention
is used and clients are able to address brokers+destinations dynamically.
-Matt
