[
https://issues.apache.org/jira/browse/ARTEMIS-780?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
clebert suconic closed ARTEMIS-780.
-----------------------------------
> 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
> Fix For: 2.0.0
>
> Attachments: Artemis780.odt
>
>
> 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.4.14#64029)
