root
/
rabbitmq-server
mirror of https://github.com/rabbitmq/rabbitmq-server.git
1
0
Fork 0
Code Issues Actions 10 Packages Projects Releases Wiki Activity
rabbitmq-server/deps/rabbit_common/include/resource.hrl

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

15 lines
477 B
Erlang
Raw Permalink Normal View History

Switch to Mozilla Public License 2.0 (MPL 2.0)
2020-07-07 23:56:14 +08:00
%% This Source Code Form is subject to the terms of the Mozilla Public
%% License, v. 2.0. If a copy of the MPL was not distributed with this
%% file, You can obtain one at https://mozilla.org/MPL/2.0/.
Make #amqqueue{} a private record See the corresponding commit in rabbitmq-server for all the explanations. Now, all accesses to the #amqqueue{} record are made through the `amqqueue` module (available in rabbitmq-server). The new type name is `amqqueue:amqqueue()`. The `amqqueue.hrl` header also provides some macros to help with pattern matching and guard expressions. To help with this, code and modules were moved from rabbitmq-common to rabbitmq-server. [#159298729]
2018-10-11 18:17:48 +08:00
%%
More missed (c) header updates
2024-01-23 12:44:47 +08:00
%% Copyright (c) 2007-2024 Broadcom. All Rights Reserved. The term “Broadcom” refers to Broadcom Inc. and/or its subsidiaries. All rights reserved.
Make #amqqueue{} a private record See the corresponding commit in rabbitmq-server for all the explanations. Now, all accesses to the #amqqueue{} record are made through the `amqqueue` module (available in rabbitmq-server). The new type name is `amqqueue:amqqueue()`. The `amqqueue.hrl` header also provides some macros to help with pattern matching and guard expressions. To help with this, code and modules were moved from rabbitmq-common to rabbitmq-server. [#159298729]
2018-10-11 18:17:48 +08:00
%%
-record(resource, {
virtual_host,
Support Will Delay Interval Previously, the Will Message could be kept in memory in the MQTT connection process state. Upon termination, the Will Message is sent. The new MQTT 5.0 feature Will Delay Interval requires storing the Will Message outside of the MQTT connection process state. The Will Message should not be stored node local because the client could reconnect to a different node. Storing the Will Message in Mnesia is not an option because we want to get rid of Mnesia. Storing the Will Message in a Ra cluster or in Khepri is only an option if the Will Payload is small as there is currently no way in Ra to **efficiently** snapshot large binary data (Note that these Will Messages are not consumed in a FIFO style workload like messages in quorum queues. A Will Message needs to be stored for as long as the Session lasts - up to 1 day by default, but could also be much longer if RabbitMQ is configured with a higher maximum session expiry interval.) Usually Will Payloads are small: They are just a notification that its MQTT session ended abnormally. However, we don't know how users leverage the Will Message feature. The MQTT protocol allows for large Will Payloads. Therefore, the solution implemented in this commit - which should work good enough - is storing the Will Message in a queue. Each MQTT session which has a Session Expiry Interval and Will Delay Interval of > 0 seconds will create a queue if the current Network Connection ends where it stores its Will Message. The Will Message has a message TTL set (corresponds to the Will Delay Interval) and the queue has a queue TTL set (corresponds to the Session Expiry Interval). If the client does not reconnect within the Will Delay Interval, the message is dead lettered to the configured MQTT topic exchange (amq.topic by default). The Will Delay Interval can be set by both publishers and subscribers. Therefore, the Will Message is the 1st session state that RabbitMQ keeps for publish-only MQTT clients. One current limitation of this commit is that a Will Message that is delayed (i.e. Will Delay Interval is set) and retained (i.e. Will Retain flag set) will not be retained. One solution to retain delayed Will Messages is that the retainer process consumes from a queue and the queue binds to the topic exchange with a topic starting with `$`, for example `$retain/#`. The AMQP 0.9.1 Will Message that is dead lettered could then be added a CC header such that it won't not only be published with the Will Topic, but also with `$retain` topic. For example, if the Will Topic is `a/b`, it will publish with routing key `a/b` and CC header `$retain/a/b`. The reason this is not implemented in this commit is that to keep the currently broken retained message store behaviour, we would require creating at least one queue per node and publishing only to that local queue. In future, once we have a replicated retained message store based on a Stream for example, we could just publish all retained messages to the `$retain` topic and thefore into the Stream. So, for now, we list "retained and delayed Will Messages" as a limitation that they actually won't be retained.
2023-05-18 23:36:25 +08:00
%% exchange, queue, topic
Make #amqqueue{} a private record See the corresponding commit in rabbitmq-server for all the explanations. Now, all accesses to the #amqqueue{} record are made through the `amqqueue` module (available in rabbitmq-server). The new type name is `amqqueue:amqqueue()`. The `amqqueue.hrl` header also provides some macros to help with pattern matching and guard expressions. To help with this, code and modules were moved from rabbitmq-common to rabbitmq-server. [#159298729]
2018-10-11 18:17:48 +08:00
kind,
%% name as a binary
name
}).