root
/
rabbitmq-server
mirror of https://github.com/rabbitmq/rabbitmq-server.git
1
0
Fork 0
Code Issues Actions Packages Projects Releases Wiki Activity
rabbitmq-server/deps/rabbitmq_jms_topic_exchange
History
Jean-Sébastien Pédron 94b8689284
Reorganize data in the Khepri store 
[Why]

The previous layout followed the flat structure we have in Mnesia:
* In Mnesia, we have tables named after each purpose (exchanges, queues,
  runtime parameters and so on).
* In Khepri, we had about the same but the table names were replaced by
  a tree node in the tree. We ended up with one tree node per purpose
  at the root of the tree.

Khepri implements a tree. We could benefit from this and organize data
to reflect their relationship in RabbitMQ.

[How]

Here is the new hierarchy implemented by this commit:

    rabbitmq
    |-- users
    |   `-- $username
    |-- vhosts
    |   `-- $vhost
    |       |-- user_permissions
    |       |   `-- $username
    |       |-- exchanges
    |       |   `-- $exchange
    |       |       |-- bindings
    |       |       |   |-- queue
    |       |       |   |   `-- $queue
    |       |       |   `-- exchange
    |       |       |       `-- $exchange
    |       |       |-- consistent_hash_ring_state
    |       |       |-- jms_topic
    |       |       |-- recent_history
    |       |       |-- serial
    |       |       `-- user_permissions
    |       |           `-- $username
    |       |-- queues
    |       |   `-- $queue
    |       `-- runtime_params
    |           `-- $param_name
    |-- runtime_params
    |   `-- $param_name
    |-- mirrored_supervisors
    |   `-- $group
    |       `-- $id
    `-- node_maintenance
        `-- $node

We first define a root path in `rabbit/include/khepri.hrl` as
`[rabbitmq]`. This could be anything, including an empty path.

All paths are constructed either from this root path definition (users
and vhosts paths do that), or from a parent resource's path (exchanges
and queues paths are based on a vhost path).
 		2024-09-05 15:31:29 +02:00
..
include More missed (c) header updates 2024-01-23 11:26:29 -05:00
src Reorganize data in the Khepri store 2024-09-05 15:31:29 +02:00
test Remove unused imports (thanks elp!) 2024-05-23 16:36:08 +02:00
BUILD.bazel Allow to use Khepri database to store metadata instead of Mnesia 2023-09-29 16:00:11 +02:00
CODE_OF_CONDUCT.md Replace files with symlinks 2022-04-15 06:04:29 -07:00
CONTRIBUTING.md Replace files with symlinks 2022-04-15 06:04:29 -07:00
LICENSE Replace @rabbitmq.com addresses with rabbitmq-core@groups.vmware.com 2023-06-20 15:40:13 +04:00
LICENSE-MPL-RabbitMQ Revert drop of Exhibit B on MPL 2.0 2020-07-20 17:00:15 +01:00
Makefile Add mnesia to LOCAL_DEPS in rabbitmq_jms_topic_exchange 2023-10-16 18:10:50 +02:00
README.md Update (c) according to [1] 2023-11-21 23:18:22 -05:00
app.bzl Allow to use Khepri database to store metadata instead of Mnesia 2023-09-29 16:00:11 +02:00

README.md

RabbitMQ JMS Topic Exchange Plugin

Overview

This plugin adds server-side support for RabbitMQ JMS client. This plugin provides support for JMS topic routing and selection based on JMS SQL selection rules.

This implementation is based upon the Java Messaging Service Specification Version 1.1.

Project Maturity

RabbitMQ JMS-related projects are several years old and can be considered reasonably mature. They have been first open sourced in June 2016. Some related projects (e.g. a compliance test suite) and documentation are yet to be open sourced.

Supported RabbitMQ Versions

This plugin ships with RabbitMQ.

Installation

Like all other plugins, this plugin must be enabled before it can be used. Enable it with

[sudo] rabbitmq-plugins enable rabbitmq_jms_topic_exchange

Design

The plugin this generates is a user-written exchange type for RabbitMQ client use. The exchange type name is "x-jms-topic" but this is not a topic exchange. Instead it works together with a standard topic exchange to provide the JMS topic selection function.

When JMS Selectors are used on a Topic Destination consumer, the destination (queue) is bound to an exchange of type x-jms-topic, with arguments that indicate what the selection criteria are. The x-jms-topic exchange is, in turn, bound to the standard Topic Exchange used by JMS messaging (this uses the RabbitMQ exchange-to-exchange binding extension to the AMQP 0-9-1 protocol).

In this way, normal topic routing can occur, with the overhead of selection only applying when selection is used, and after the routing and filtering implied by the topic name.

Copyright and License

(c) 2007-2023 Broadcom. All Rights Reserved. The term “Broadcom” refers to Broadcom Inc. and/or its subsidiaries.

See LICENSE for license information.