> 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.
All of that is already in place. To be clear, subscriptions are just queues (whether that's for JMS, STOMP, MQTT, etc.). > IHMO using the same prefix across protocols as much as possible would be > super dope. I think we'd want to make this configurable so that it would be up to users. > Other messaging systems (namely, IBM MQ Remote Queues, Cluster Queues) > support fully qualified destination names. This seems to me beyond the scope of this work. The addressing improvements here are all intra-broker. I'm in favor of keeping the work narrowly focused so our objectives remain clear. Justin ----- Original Message ----- From: "Matt Pavlovich" <[email protected]> To: [email protected] Sent: Wednesday, November 16, 2016 3:38:41 PM Subject: Re: [DISCUSS] Artemis addressing improvements, JMS component removal and potential 2.0.0 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
