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 <[email protected]> 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?
2. MQTT always requires a subscription? I don't find that to be the
case. You can produce without a subscriber/consumer, no?
!! 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.
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.
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?
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:
"foo.bar" (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 "foo.bar" 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.
-Matt
