[ https://issues.apache.org/jira/browse/ARTEMIS-780?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15664260#comment-15664260 ]
John D. Ament commented on ARTEMIS-780: --------------------------------------- [~martyntaylor] Would it make sense to put this out on confluence? Is there one for artemis, or perhaps a directory on the activemq one? > 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 > 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.3.4#6332)