activemq-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ASF subversion and git services (JIRA)" <>
Subject [jira] [Commented] (ARTEMIS-780) Improve addressing, routing and JMS configuration in Artemis
Date Mon, 12 Dec 2016 20:35:58 GMT


ASF subversion and git services commented on ARTEMIS-780:

Commit 8655d1a3d80d6afae527d36f01f525d078afeebb in activemq-artemis's branch refs/heads/master
from [~martyntaylor]
[;h=8655d1a ]

ARTEMIS-780 Check for HDR_ROUTING_TYPE in PostOffice

> Improve addressing, routing and JMS configuration in Artemis
> ------------------------------------------------------------
>                 Key: ARTEMIS-780
>                 URL:
>             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

View raw message