activemq-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Martyn Taylor (JIRA)" <j...@apache.org>
Subject [jira] [Created] (ARTEMIS-780) Improve addressing, routing and JMS configuration in Artemis
Date Mon, 10 Oct 2016 11:43:20 GMT
Martyn Taylor created ARTEMIS-780:
-------------------------------------

             Summary: 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: Improvement
            Reporter: 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)

Mime
View raw message