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 Fri, 18 Nov 2016 12:01:53 GMT
On Thu, Nov 17, 2016 at 1:56 PM, Matt Pavlovich <> wrote:

> On 11/17/16 5:49 AM, Martyn Taylor wrote:
> This is great feedback Matt, thanks.  I have a couple of questions/comments
>> below:
>> On Wed, Nov 16, 2016 at 6:23 PM, Matt Pavlovich <>
>> wrote:
> <snip..>
>> Just so I understand exactly what you are saying here.  You're saying that
>> a client sends to "foo" and a consumer received messages sent to "foo".
>> In
>> order for the consumer to consume from "foo" it passes in either "foo",
>> "queue:///foo" or "topic:///foo" which determines how the messages are
>> propagated to the client?  "foo" means let the broker decide,
>> "queue:///foo" and "topic:///foo" mean let the client decide.  In addition
>> to these two approaches, it may be that the protocol itself wants to
>> decide.  MQTT for example, always requires a subscription.
> 1. I hadn't thought of "prefix-less" destinations (aka "foo").  Are you
> thinking Artemis throws an exception if there is an overlap in destination
> names and it can't auto-resolve?
 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.

> 2. MQTT always requires a subscription? I don't find that to be the case.
> You can produce without a subscriber/consumer, no?
I was talking about the consumer behaviour only.

>   !! Warning probably off-topic!! a major gap in MQTT is its lack of
> queues/PTP/unicast. Being able to use the MQTT wire protocol to send to
> queues would be really useful.  ActiveMQ 5.x allows wiring MQTT protocol to
> use virtual topics for consumption, which is a big win.
> 3. The rub seems to be that JMS leans to having a definitive split b/w
> Topic and Queue, whereas STOMP and AMQP just have addresses and MQTT is
> topic-only-ish.

And Artemis CORE only has queues and addresses.  What we want to ensure is
that the CORE engine is capable of supporting all of the requirements for
JMS, MQTT and other protocols.


> One way to do this, not straying too far from the original proposal, would
>> be to make the address uniqueness a combination of the routing type and
>> the
>> address name.  This would allow something like:
>> <address name="foo" routingType="anycast">
>> <address name="foo" routingType="multicast">
>> We'd need to ensure there is a precedent set for times when a subscriber
>> just subscribes to "foo".  I'd say it makes sense for "multicast" to take
>> precedence in this case.
> I'd disagree that we should have a precedence behavior. It too easily
> break if I produce JMS queue:///FOO and consume STOMP "foo" I wouldn't
> receive the message.

> I think an unqualified address should throw an exception when there is an
> overlap.

That's another approach.  Seems reasonable.  We could make it configurable
on a per protocol basis.


> I think it probably makes the most sense to have the following precedence
>> for the deciding party:
>> 1. Broker
>> 2. Address prefixing/name scheme
>> 3. Protocol
>> I think the prefix also needs to be configurable, but "queue:///"
>> "topic:///" seems like a sensible default.
> +1
>> 3. As far as destination behaviors, how about using uri parameters to pass
>>> provider (Artemis) specific settings on-the-fly?
>>>      For example:  in AMPQ the address could be
>>> topic:///foo?type=nonSharedNonDurable etc..  same for MQTT, STOMP, etc.
>>>      There is precedence in using uri parameters to configure the
>>> Destination in JMS as well. IBM MQ has session.createQueue("My.Queue?
>>> targetClient=1")
>>>      Note: AMQP supports options as well, so that could be used as well.
>>> However, uri's tend to be better for externalizing configuration
>>> management.
>>> I think supporting both options, uri and protocol specific parameters is
>> useful.  Rather than "nonSharedDurable" I think I'd prefer to map these
>> things onto address properties.  For example:
>> "topic://foo?maxConsumers=1"
>> Where the "topic:///" prefix is configurable.  This is essentially a non
>> shared, durable subscription.
> I'm not married to any naming convention, but I it should reflect both the
> durability and "shared-ness". Regarding maxConsumers=1, are you thinking
> you'd want to limit "shared-ness" to an integer or true | false?
> ie.. would maxConsumer=3 limit shared consumers to three threads?

It would limit it to 3 server consumers.

N.B. The threading model in Artemis is different to ActiveMQ 5.x, we use
shared thread pools.

> 4. Destination name separation b/w protocol handlers.  STOMP and MQTT like
>>> "/" and JMS likes "." as destination name separators. Is there any
>>> thought
>>> to having a native destination name separator and then have
>>> protocol-specific convertors?
>>> This is how it works right now.  We have a native path separator which is
>> ".".  Protocol handlers map subscription addresses down to this.  This
>> does
>> mean that to define a multicast address for MQTT, you would need to do:
>> "" (vs "foo/bar" which is protocol specific).
>> I've also outlined in the proposal a goal to allow these path separators
>> to
>> be configurable.  So you can specify pathSeparator="/", "." which would
>> mean that you can configure "foo/bar" or "" they'd both act in the
>> same way.
> +1 Configurable separator sounds good, I recommend that be a broker-wide
> config option and accessible by plugins so they can reference it correctly
> w/o presuming ".".
> 5. Fully qualified destination names that include a broker name. Other
>>> providers support fully-qualified destination names in JMS following the
>>> format:  queue://$brokerName/$queueName. Adding this would go a long way
>>> to supporting migration of current applications without having to change
>>> client-code.
>>> This is a little differently to how clustering currently works, I think
>> we
>> need to give this one some more thought.  Right now queues are clustered
>> automatically (well providing you enable the correct address namespace for
>> the cluster connection).  If you have a client listening on broker2 and a
>> producer from broker1, the messages will get propagated across the
>> cluster.
>> You may have already explained this to me in the past, but can you give me
>> an example use case of when this might be necessary.
> IoT/Retail Store/Kiosk scenario:
> The use case is "clustered brokers, non-clustered destinations". ie. Same
> simple queue name exist on all "edge" brokers, but the subscriptions are
> unique per edge broker.
> An IOT device comes online and its broker creates a duplex connection to
> central broker. IoT devices sends a "Hello World" to
> queue://central/HELLO.REQUEST with a replyTo of
> queue://iot1234/HELLO.RESPONSE.
> The central application receives the event, creates response and addresses
> the response to queue://iot1234/HELLO.RESPONSE. The message is then sent
> to the "central" broker who routes the message to the "iot1234" broker over
> the duplex connection which delivers it to the local
> queue:///HELLO.RESPONSE.
> 1. Edge device applications are all coded using the same queue names to
> keep things simple
> 2. Central applications are unaware and do not need to manage the the
> url's of edge brokers
> 3. Central broker handles routing, similar to email MTA
> 4. IBM MQ, Tibco EMS (~90% of EMS market share), and others support this
> and its heavily utilized.
> Thanks.  I think I still need more information/thought to fully understand
this and how it might work in Artemis.

> -Matt

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