[jira] [Updated] (ARTEMIS-780) Improve addressing, routing and JMS configuration in Artemis

["Martyn Taylor (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/ARTEMIS-780?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Martyn Taylor updated ARTEMIS-780:
----------------------------------
    Issue Type: New Feature  (was: Improvement)

> Improve addressing, routing and JMS configuration in Artemis
> ------------------------------------------------------------
>
>                 Key: ARTEMIS-780
>                 URL: https://issues.apache.org/jira/browse/ARTEMIS-780
>             Project: ActiveMQ Artemis
>          Issue Type: New Feature
>            Reporter: Martyn Taylor
>            Assignee: Martyn Taylor
>
> 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).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)