[
https://issues.apache.org/jira/browse/ARTEMIS-780?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16299104#comment-16299104
]
ASF subversion and git services commented on ARTEMIS-780:
---------------------------------------------------------
Commit 9d685b6f2d6b880120f0b75100d351933b395df0 in activemq-artemis's branch
refs/heads/master from [~jdanek]
[ https://git-wip-us.apache.org/repos/asf?p=activemq-artemis.git;h=9d685b6 ]
ARTEMIS-1183 Delete empty "queue-attributes.html" doc page
This is a follow-up to ARTEMIS-780 Added section on latest address model
> 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)
