activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martyn Taylor <mtay...@redhat.com>
Subject [DISCUSS] Artemis addressing improvements, JMS component removal and potential 2.0.0
Date Wed, 16 Nov 2016 15:16:02 GMT
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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message