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 Thu, 17 Nov 2016 10:49:50 GMT
This is great feedback Matt, thanks.  I have a couple of questions/comments

On Wed, Nov 16, 2016 at 6:23 PM, Matt Pavlovich <> wrote:

> Hi Martin-
> Glad to see this area getting dedicated attention. A couple things I
> didn't see covered in the doc or the JIRA comments. (I'll be adding to the
> JIRA comments as well.)
> Items:
> 0. Pre-configuring destinations is a big brain drain, so anything that can
> be client-driven is a win. Also, protocol specific handlers could perform
> the admin operations on-demand.
>    For example:  session.createDurableSubscriber(...)   The JMS handler
> create the subscription on the behalf of the client.
Yes I agree.  We need to ensure we can both ways of defining the endpoint
semantics, i.e. allow clients to request endpoint requirements and also
have broker side configuration drive endpoint behaviour, ideally using the
same underlying mechanism.

> 1. Separate topic and queue namespaces.. in JMS topic:///foo !=
> queue:///foo. The addressing will need some sort of way to separate the two
> during naming collisions.
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.

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 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.

> 2. In ActiveMQ 5.x, AMQP and STOMP handled the addressing by using
> queue:/// and topic:/// prefixes. I don't think that is necessarily a bad
> thing, but something to consider b/c we need to support #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:


Where the "topic:///" prefix is configurable.  This is essentially a non
shared, durable subscription.

> 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.

> 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.

>     Note: This would probably impact cluster handling as well, so perhaps
> in phase 1 there is just a placeholder for supporting a broker name in the
> future?
> -Matt


> On 11/16/16 10:16 AM, Martyn Taylor wrote:
>> All,
>> Some discussion has happened around this topic already, but I wanted to
>> ensure that everyone here, who have not been following the
>> branch has a chance for input and to digest the information in this
>> proposal.
>> In order to understand the motivators outlined here, you first need to
>> understand how the existing addressing model works in Artemis. For those
>> of
>> you who are not familiar with how things currently work, I’ve added a
>> document to the ARTEMIS-780 JIRA in the attachments section, that gives an
>> overview of the existing model and some more detail / examples of the
>> proposal: *
>> <>*
>> To summarise here, the Artemis routing/addressing model has some
>> restrictions:
>> 1. It’s not possible with core (and therefore across all protocols) to
>> define ,at the broker side, semantics about addresses. i.e. whether an
>> address behaves as a “point to point” or “publish subscribe” end point
>> 2. For JMS destinations additional configuration and objects were added to
>> the broker, that rely on name-spacing to add semantics to addresses i.e.
>> “jms.topic.” “jms.queue.”  A couple of issues with this:
>>     1.
>>     This only works for JMS and no other protocols
>>     2.
>>     Name-spacing causes issues for cross protocol communication
>>     3.
>>     It means there’s two ways of doing things, 1 for JMS and 1 for
>>     everything else.
>> 3. The JMS and Core destination definitions do not have enough information
>> to define more intricate behaviours. Such as whether an address should
>> behave like a “shared subscription” or similar to a “volatile
>> subscription”
>> where clients don’t get messages missed when they are offline.
>> 4. Some protocols (AMQP is a good example) don’t have enough information
>> in
>> their frames for the broker to determine how to behave for certain
>> endpoints and rely on broker side configuration (or provider specific
>> parameters).
>> Proposal
>> What I’d like to do (and what I’ve proposed in ARTEMIS-780) is to get rid
>> of the JMS specific components and create a single unified mechanism for
>> configuring all types of endpoints across all protocols to define:
>>     -
>>     Point to point (queue)
>>     -
>>     Shared Durable Subscriptions
>>     -
>>     Shared Non Durable Subscriptions
>>     -
>>     Non Shared durable subscriptions
>>     -
>>     Non Shared Non durable subscriptions
>> To do this, the idea is to create a new “Address” configuration/management
>> object, that has certain properties such as a routing type which
>> represents
>> how messages are routed to queues with this address.
>> When a request for subscription is received by Artemis, the relevant piece
>> can just look up the address and check it’s properties to determine how to
>> behave (or if an address doesn’t exist) then default to our existing
>> behaviour. For those interested in the details of how this might work I’ve
>> outlined some specific examples in the document on the JIRA.
>> What are the user impacts:
>> 1. Configuration would need to be revised in order to expose the new
>> addressing object. I propose that we either continue supporting the old
>> schema for a while and/or provide a tool to migrate the configuration
>> schema.
>> 2. Some new management operations would need to be added to expose the new
>> objects.
>> 3. The JMS configuration and management objects would become obsolete, and
>> would need removing. The Broker side JMS resources were only a thin facade
>> to allow some JMS specific behaviour for managing destinations and for
>> things like registering objects in JNDI.
>> Broker side JNDI was removed in Artemis 1.0 in order to align with
>> ActiveMQ
>> 5.x style of client side JNDI.  These JMS pieces and their management
>> objects don't really do much, creating connection factories for instance
>> offers no functionality right now.  Going forward, users should be able to
>> use the core management API to do everything.
>> 4. All client applications should behave exactly as they were before. The
>> proposal is for adding features to the core model, not removing any.  For
>> things like the Artemis JMS client which relied on name-spaces, they’ll be
>> a mechanism to define a name-spaced address and a mechanism to switch back
>> on name-spaces in the client.
>> 5. Given some of the API changes and removal of the JMS specific pieces.
>> This would likely warrant a major bump. i.e. Artemis 2.0.0.
>> Whilst I’ve been looking at this, it’s become apparent, that the JMS
>> pieces
>> have leaked into lots of areas of the code base, which does mean we’d need
>> to do a fair amount refactoring to move these bits to the new model.
>> In my opinion this proposal can only be a good thing. It creates a single
>> place (core) where all addressing objects are configured and managed and
>> allows all protocol managers to plug into the same mechanism. It solves
>> some of the cross protocol JMS → other protocols that we’ve seen users
>> struggle with, but still offers a way to support all the old behaviour in
>> client applications.
>> What are others thoughts on this? Any suggestions, comments or concerns?
>> Regards
>> Martyn

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