activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matt Pavlovich <mattr...@gmail.com>
Subject Re: [DISCUSS] Artemis addressing improvements, JMS component removal and potential 2.0.0
Date Fri, 18 Nov 2016 18:26:12 GMT
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 <mattrpav@gmail.com> 
>> 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.
>>
>


Mime
View raw message