[ARTEMIS-780] Improve addressing, routing and JMS configuration in Artemis

• Type: New Feature
• Status: Closed
• Priority: Major
• Resolution: Fixed
• Fix Version/s: 2.0.0
• Assignee: Martyn Taylor
• Reporter: Martyn Taylor
• Created: 10/Oct/16 11:42
• Updated: 20/Dec/17 21:08
• Resolved: 10/Mar/17 11:52

Description

There are a couple of issues with the way Artemis handles addressing of various destination types. The core of Artemis is based solely on multicast and queue semantics. i.e. Artemis core supports the ability to define queues and associate them to addresses. When a message is received it is forwarded to all the queues with matching addresses.

This works well for Artemis Core clients, core clients send to addresses and receive from queues. If an application using the core client want pub/sub semantics, the client can manage it's own queues, using the Core protocol to create and delete queues.

However, this model falls down with other protocols, that don't support the "create", "delete" and "lookup" queue management packets. AMQP for example struggles with this.

There's also the issue of broker side configuration. Right now users are not able to configure address space (outside of JMS) to define publish/subscribe semantics for addresses. It is possible to configure a special queue with certain properties that will give Artemis a hint that this address should behave as publish/subscribe but this is just a side effect of how JMS Topics are implemented in the core client.

Instead, we should update the way we are using addresses in Artemis and allow users to be specific about the semantics they require on certain address spaces.

One way to do this without diverting from Artemis core concepts would be to expose Addresses as first class citizens in the management API and configuration. Properties (such as routing semantics) can be added to addresses to identify the way in which address spaces should work. This would also allow users to define addresses consistently across all protocols including JMS (we can drop the special JMS configuration and allow users to specify "queues" and "topics" in Artemis CORE concepts. This would also provide a single view in Artemis management (they'd be no need to have a special JMS management section).

Issue Links

• is depended upon by: ARTEMIS-796 Add support for advisory messages
• relates to: ARTEMIS-922 Clean up addressing API

Sub-Tasks

• Create Address Journal Record Type: Closed
• Add new configuration schema that includes first class Address elements: Closed
• Implement "anycast" routing in Artemis PostOffice: Closed
• Add new management methods to include new first class addresses: Closed
• Update Examples to use new configuration: Closed
• Update core client wireformat to support new addressing scheme: Closed
• Update MQTT& STOMP to check that addresses are multicast: Closed
• Update Tests: Closed
• Create a Configv1 to Configv2 transformation tool: Closed
• Define XSD for new configuration: Closed
• Store Address Data and AutoCreate Address on Queue Load/Create: Closed
• Make address path separator configurable: Closed
• Remove JMS stuff from code-base: Closed
• Update various protocols to deal with new addressing scheme: Closed
• Update CLI: Closed
• Implement new security roles for addresses: Closed
• Support address prefixing: Closed
• Add new address-settings to deal with new config options: Closed