activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Timothy Bish <>
Subject Re: [DISCUSS] Artemis addressing improvements, JMS component removal and potential 2.0.0
Date Wed, 16 Nov 2016 19:07:03 GMT
<cough>....JMS is not a protocol....<cough>

On 11/16/2016 01:39 PM, Justin Bertram wrote:
> Some additional historical context from my personal observations...
> The "jms.queue." and "jms.topic." queue/address prefixes were put in place years ago
when the code-base was relatively young.  This was before my time but I believe this was done
because it was an extremely simple (and effective) solution to the problem of how to provide
different semantics between JMS and core.  JMS was the first and only non-core protocol supported
by the broker for a long time.  As other protocols were implemented the whole prefix notion
was recognized as a weakness (e.g. see ARTEMIS-203).  Since the donation to Apache significant
work has been done on other protocols like AMQP, MQTT, and STOMP.  IMO, this has pressed the
issue to the point of action.
> I think making the changes that Martyn has outlined will provide a better foundation
for the long-term of health of Artemis which is an increasingly multi-protocol broker.  It
should make the broker simpler which will be a win for configuration as well as maintenance
and new protocol integration.
> Justin
> ----- Original Message -----
> From: "Martyn Taylor" <>
> To:
> Sent: Wednesday, November 16, 2016 9:16:02 AM
> Subject: [DISCUSS] Artemis addressing improvements, JMS component removal and potential
> 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: *
> <>*
> 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

Tim Bish
twitter: @tabish121

View raw message