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 Wed, 16 Nov 2016 18:23:11 GMT
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
>


Mime
View raw message