0. Auto-creation for JMS queues and topics was already supported, and I expect
that will continue.
1. I'm not sure I understand the use-case for having a topic and queue with the
same name. Can you clarify 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.
3. I think using URIs has merit, but each protocol has nuances that would
probably make something universal impossible.
4. See ARTEMIS-815 (sub-task of ARTEMIS-780).
5. Can you clarify this a bit more? An example would be great.
Justin
----- Original Message -----
From: "Matt Pavlovich" <mattr...@gmail.com>
To: dev@activemq.apache.org
Sent: Wednesday, November 16, 2016 12:23:11 PM
Subject: Re: [DISCUSS] Artemis addressing improvements, JMS component removal
and potential 2.0.0
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.
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.
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.
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?
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.
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 JIRA/ARTEMIS-780
> 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: *https://issues.apache.org/jira/browse/ARTEMIS-780
> <https://issues.apache.org/jira/browse/ARTEMIS-780>*
>
> 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
>
