Java RabbitMQ AMQP.BasicProperties.Builder 值

RabbitMQ AMQP.BasicProperties.Builder values

提问by

In the RabbitMQ/AMQP Java client, you can create an AMQP.BasicProperties.Builder, and use it to build()an instance of AMQP.BasicProperties. This built properties instance can then be used for all sorts of important things. There are lots of "builder"-style methods available on this builder class:

在RabbitMQ的/ AMQP Java客户端，您可以创建一个AMQP.BasicProperties.Builder，并用它来build()的一个实例AMQP.BasicProperties。这个构建的属性实例可以用于各种重要的事情。此构建器类中有许多“构建器”样式的方法可用：

BasicProperties.Builder propsBuilder = new BasicProperties.Builder();
propsBuilder
    .appId(???)
    .clusterId(???)
    .contentEncoding(???)
    .contentType(???)
    .correlationId(???)
    .deliveryMode(2)
    .expiration(???)
    .headers(???)
    .messageId(???)
    .priority(???)
    .replyTo(???)
    .timestamp(???)
    .type(???)
    .userId(???);

I'm looking for what fields these builer methods help "build-up", and most importantly, what valid values exist for each field. For instance, what is a clusterId, and what are its valid values? What is type, and what are its valid values? Etc.

我正在寻找这些构建器方法有助于“构建”哪些字段，最重要的是，每个字段存在哪些有效值。例如，什么是 a clusterId，它的有效值是什么？什么是type，它的有效值是什么？等等。

I have spent all morning scouring:

我整个上午都在搜索：

• The Java client documentation; and
• The Javadocs; and
• The RabbitMQ full reference guide; and
• The AMQP specification

• Java 客户端文档；和
• Javadocs; 和
• RabbitMQ 完整参考指南；和
• AMQP 规范

In all these docs, I cannot find clear definitions (besides some vagueexplanation of what priority, contentEncodingand deliveryModeare) of what each of these fields are, and what their valid values are. Does anybody know? More importantly, does anybody know where these are even documented? Thanks in advance!

在所有这些文档，我无法找到明确的定义（除了一些含糊的解释是什么priority，contentEncoding以及deliveryMode是）什么的每个领域都，以及他们的有效值。有人知道吗？更重要的是，有人知道这些甚至记录在哪里吗？提前致谢！

采纳答案by Renat Gilmanov

Usually I use very simple approach to memorize something. I will provide all details below, but here is a simple picture of BasicProperties field and values. I've also tried to properly highlight queue/server and application context.

通常我使用非常简单的方法来记住一些东西。我将在下面提供所有详细信息，但这里是 BasicProperties 字段和值的简单图片。我还尝试正确突出显示队列/服务器和应用程序上下文。

If you want me to enhance it a bit - just drop a small comment. What I really want is to provide some visual key and simplify understanding.

如果你想让我稍微增强它 - 只需留下一个小评论。我真正想要的是提供一些视觉键并简化理解。

High-level description(source 1, source 2):

高级描述（来源 1，来源 2）：

Please note Clust ID has been deprecated, so I will exclude it.

请注意 Clust ID 已被弃用，因此我将其排除在外。

• Application ID- Identifier of the application that produced the message.
  • Context: application use
  • Value: Can be any string.
• Content Encoding- Message content encoding
  • Context: application use
  • Value: MIME content encoding (e.g. gzip)
• Content Type- Message content type
  • Context: application use
  • Value: MIME content type (e.g. application/json)
• Correlation ID- Message correlated to this one, e.g. what request this message is a reply to. Applications are encouraged to use this attribute instead of putting this information into the message payload.
  • Context: application use
  • Value: any value
• Delivery mode- Should the message be persisted to disk?
  • Context: queue implementation use
  • Value: non-persistent (1) or persistent (2)
• Expiration- Expiration time after which the message will be deleted. The value of the expiration field describes the TTL period in milliseconds. Please see details below.
  • Context: queue implementation use
• Headers- Arbitrary application-specific message headers.
  • Context: application use
• Message ID- Message identifier as a string. If applications need to identify messages, it is recommended that they use this attribute instead of putting it into the message payload.
  • Context: application use
  • Value: any value
• Priority- Message priority.
  • Context: queue implementation use
  • Values: 0 to 9
• ReplyTo- Queue name other apps should send the response to. Commonly used to name a reply queue (or any other identifier that helps a consumer application to direct its response). Applications are encouraged to use this attribute instead of putting this information into the message payload.
  • Context: application use
  • Value: any value
• Time-stamp- Timestamp of the moment when message was sent.
  • Context: application use
  • Value: Seconds since the Epoch.
• Type- Message type, e.g. what type of event or command this message represents. Recommended to be used by applications instead of including this information into the message payload.
  • Context: application use
  • Value: Can be any string.
• User ID- Optional user ID. Verified by RabbitMQ against the actual connection username.
  • Context: queue implementation use
  • Value: Should be authenticated user.

• 应用程序 ID- 生成消息的应用程序的标识符。
  • 上下文：应用程序使用
  • 值：可以是任何字符串。
• 内容编码- 消息内容编码
  • 上下文：应用程序使用
  • 值：MIME 内容编码（例如 gzip）
• 内容类型- 消息内容类型
  • 上下文：应用程序使用
  • 值：MIME 内容类型（例如 application/json）
• 相关 ID- 与此相关的消息，例如此消息是对什么请求的回复。鼓励应用程序使用此属性，而不是将此信息放入消息有效负载中。
  • 上下文：应用程序使用
  • 值：任意值
• 传递模式- 消息是否应该保存到磁盘？
  • 上下文：队列实现使用
  • 值：非持久性 (1) 或持久性 (2)
• Expiration- 过期时间，在此之后消息将被删除。expire 字段的值以毫秒为单位描述 TTL 周期。请参阅下面的详细信息。
  • 上下文：队列实现使用
• 标头- 任意特定于应用程序的消息标头。
  • 上下文：应用程序使用
• 消息 ID- 作为字符串的消息标识符。如果应用程序需要识别消息，建议他们使用此属性，而不是将其放入消息负载中。
  • 上下文：应用程序使用
  • 值：任意值
• 优先级- 消息优先级。
  • 上下文：队列实现使用
  • 值：0 到 9
• ReplyTo- 其他应用程序应将响应发送到的队列名称。通常用于命名回复队列（或任何其他帮助消费者应用程序引导其响应的标识符）。鼓励应用程序使用此属性，而不是将此信息放入消息有效负载中。
  • 上下文：应用程序使用
  • 值：任意值
• 时间戳- 发送消息时的时间戳。
  • 上下文：应用程序使用
  • 值：自纪元以来的秒数。
• 类型- 消息类型，例如该消息代表什么类型的事件或命令。建议由应用程序使用，而不是将此信息包含在消息负载中。
  • 上下文：应用程序使用
  • 值：可以是任何字符串。
• 用户 ID- 可选的用户 ID。由 RabbitMQ 针对实际连接用户名进行验证。
  • 上下文：队列实现使用
  • 值：应该是经过身份验证的用户。

BTW, I've finally managed to review latest sever code (rabbitmq-server-3.1.5), there is an example in rabbit_stomp_test_util.erl:

顺便说一句，我终于设法查看了最新的服务器代码（rabbitmq-server-3.1.5），rabbit_stomp_test_util.erl 中有一个示例：

                content_type     = <<"text/plain">>,
                content_encoding = <<"UTF-8">>,
                delivery_mode    = 2,
                priority         = 1,
                correlation_id   = <<"123">>,
                reply_to         = <<"something">>,
                expiration       = <<"my-expiration">>,
                message_id       = <<"M123">>,
                timestamp        = 123456,
                type             = <<"freshly-squeezed">>,
                user_id          = <<"joe">>,
                app_id           = <<"joe's app">>,
                headers          = [{<<"str">>, longstr, <<"foo">>},
                                    {<<"int">>, longstr, <<"123">>}]

Good to know somebody wants to know all the details. Because it is much better to use well-known message attributes when possible instead of placing information in the message body. BTW, basic message properties are far from being clear and useful. I would say it is better to use a custom one.

很高兴知道有人想知道所有细节。因为最好尽可能使用众所周知的消息属性，而不是在消息正文中放置信息。顺便说一句，基本的消息属性远非清晰和有用。我会说最好使用自定义的。

Good example(source)

很好的例子（来源）

Update - Expiration field

更新 - 到期字段

Important note: expirationbelongs to queue context. So message might be dropped by the servers.

重要说明：到期属于队列上下文。因此消息可能会被服务器丢弃。

README says the following:

README 说明如下：

expirationis a shortstr; since RabbitMQ will expect this to be an encoded string, we translate a ttlto the string representation of its integer value.

expiration是一个shortstr；由于 RabbitMQ 将期望这是一个编码字符串，我们将 a 转换ttl为其整数值的字符串表示形式。

Sources:

资料来源：

• Additional source 1
• Additional source 2

• 附加来源 1
• 附加来源 2

回答by Brian Kelly

The AMQPspec defines a generic, extensible model for properties.

该AMQP规范定义了一个通用的、可扩展的属性模型。

AMQP properties are somewhat similar in concept to HTTP headers, in that they represent metadata about the messages in question. Just as in HTTP, they are framed separatelyto the message payload. But they are basically a key/value map.

AMQP 属性在概念上与 HTTP 标头有些相似，因为它们表示有关消息的元数据。就像在 HTTP 中一样，它们与消息有效负载分开构建。但它们基本上是一个键/值映射。

Some brokers like RabbitMQ will interpret certain message properties like expirationto add extra vendor-specific value (in that case, enforcing a TTL).

一些像 RabbitMQ 这样的代理会解释某些消息属性，比如expiration添加额外的特定于供应商的值（在这种情况下，强制执行 TTL）。

But in the end, AMQP properties are just a big bunch of key/value pairs that get safely sent along with each message, should you choose to do so. Your AMQP broker's documentation will tell you which ones they interpret specially and how to send your own ones.

但最终，AMQP 属性只是一大堆键/值对，它们与每条消息一起安全发送，如果您选择这样做的话。您的 AMQP 经纪人的文档将告诉您他们特别解释哪些以及如何发送您自己的。

All that being said, if you're asking this question in the first place then you probably don't need to worry about them at all. You will be successfully able to send messages without having to worry about setting any message properties at all.

话虽如此，如果您首先问这个问题，那么您可能根本不需要担心它们。您将能够成功发送消息，而无需担心设置任何消息属性。

回答by Glen Best

At time of writing:

在撰写本文时：

1. The latest AMQP standard is AMQP 1.0 OASIS Standard.
2. The latest version of RabbitMQ is 3.1.5 (server and client), which claims to support AMQP 0.9.1(pdf and XML schemas zipped).
3. RabbitMQ provides it's own description of the protocol as XML schema including extensions(i.e. non-standard), plus XML schema without extensions(which is identical to the schema linked via (2)) and pdf doc.

1. 最新的 AMQP 标准是AMQP 1.0 OASIS 标准。
2. RabbitMQ 的最新版本是 3.1.5（服务器和客户端），它声称支持AMQP 0.9.1（pdf 和 XML 模式压缩）。
3. RabbitMQ 将其​​自己的协议描述提供为XML 模式，包括扩展（即非标准），加上没有扩展的 XML 模式（与通过 (2) 链接的模式相同）和pdf doc。

In this answer:

在这个答案中：

• links in (3) are the primary source of detail
• (2) pdf doc is used as secondary detail if (3) is inadequate
• The source code (java client, erlang server) is used as tertiary detail if (2) is inadequate.
• (1) is generally not used - the protocol and schema have been (fairly) significantly evolved for/by OASIS and should apply to future versions of RabbitMQ, but do not apply now. The two exceptions where (1) was used was for textual descriptions of contentTypeand contentEncoding- which is safe, because these are standard fields with good descriptions in AMQP 1.0.

• (3) 中的链接是详细信息的主要来源
• (2) 如果 (3) 不充分，则 pdf doc 用作次要细节
• 如果（2）不充分，则源代码（java 客户端、erlang 服务器）用作第三级细节。
• (1) 通常不使用 - OASIS 已经（相当）显着地改进了协议和模式，应该适用于 RabbitMQ 的未来版本，但现在不适用。其中（1）使用的两个例外是对的文字描述contentType和contentEncoding-这是安全的，因为这些都是在AMQP 1.0很好的描述标准字段。

The following text is paraphrased from these sources by me to make a little more concise or clear.

以下文字是我从这些来源中转述的，以使其更加简洁或清晰。

• content-type(AMQP XML type="shortstr"; java type="String"): Optional. The RFC-2046 MIME type for the message's application-data section (body). Can contain a charset parameter defining the character encoding used: e.g., 'text/plain; charset=“utf-8”'. Where the content type is unknown the content-type SHOULD NOT be set, allowing the recipient to determine the actual type. Where the section is known to be truly opaque binary data, the content-type SHOULD be set to application/octet-stream.
• content-encoding(AMQP XML type="shortstr"; java type="String"): Optional. When present, describes additional content encodings applied to the application-data, and thus what decoding mechanisms need to be applied in order to obtain the media-type referenced by the content-type header field. Primarily used to allow a document to be compressed without losing the identity of its underlying content type. A modifier to the content-type, interpreted as per section 3.5 of RFC 2616. Valid content-encodings are registered at IANA. Implementations SHOULD NOT use the compress encoding, except as to remain compatible with messages originally sent with other protocols, e.g. HTTP or SMTP. Implementations SHOULD NOT specify multiple content-encoding values except as to be compatible with messages originally sent with other protocols, e.g. HTTP or SMTP.
• headers(AMQP XML type="table"; java type="Map"): Optional. An application-specified list of header parameters and their values. These may be setup for application-only use. Additionally, it is possible to create queues with "Header Exchange Type" - when the queue is created, it is given a series of header property names to match, each with optional values to be matched, so that routing to this queue occurs via header-matching.
• deliveryMode(RabbitMQ XML type="octet"; java type="Integer"): 1(non-persistent) or 2(persistent). Only works for queues that implement persistence. A persistent message is held securely on disk and guaranteed to be delivered even if there is a serious network failure, server crash, overflow etc.
• priority(AMQP XML type="octet"; java type="Integer"): The relative message priority (0 to 9). A high priority message is [MAY BE?? - GB] sent ahead of lower priority messages waiting in the same message queue. When messages must be discarded in order to maintain a specific service quality level the server will first discard low-priority messages. Only works for queues that implement priorities.
• correlation-id(AMQP XML type="octet"; java type="String"): Optional. For application use, no formal (RabbitMQ) behaviour. A client-specific id that can be used to mark or identify messages between clients.
• replyTo(AMQP XML type="shortstr"; java type="String"): Optional. For application use, no formal (RabbitMQ) behaviour but may hold the name of a private response queue, when used in request messages. The address of the node to send replies to.
• expiration(AMQP XML type="shortstr"; java type="String"): Optional. RabbitMQ AMQP 0.9.1 schemafrom (3) states "For implementation use, no formal behaviour". The AMQP 0.9.1 schema pdf from (2) states an absolute time when this message is considered to be expired. However, both these descriptions must be ignoredbecause this TTL linkand the client/server code indicate the following is true. From the client, expiration is only be populated via custom application initialisation of BasicProperties. At the server, this is used to determine TTL from the point the message is received at the server, prior to queuing. The server selects TTL as the minimum of (1) message TTL (client BasicProperties expirationas a relative time in milliseconds) and (2) queue TTL (configured x-message-ttlin milliseconds). Format: string quoted integer representing number of milliseconds; time of expiry from message being received at server.
• message-id(AMQP XML type="shortstr"; java type="String"): Optional. For application use, no formal (RabbitMQ) behaviour. If set, the message producer should set it to a globally unique value. In future (AMQP 1.0), a broker MAY discard a message as a duplicate if the value of the message-id matches that of a previously received message sent to the same node.
• timestamp(AMQP XML type="timestamp"; java type="java.util.Date"): Optional. For application use, no formal (RabbitMQ) behaviour. An absolute time when this message was created.
• type(AMQP XML type="shortstr"; java type="String"): Optional. For application use, no formal (RabbitMQ) behaviour. [Describes the message as being of / belonging to an application-specific "type" or "form" or "business transaction" - GB]
• userId(AMQP XML type="shortstr"; java type="String"): Optional. XML Schema states "For application use, no formal (RabbitMQ) behaviour" - but I believe this has changed in the latest release (read on). If set, the client sets this value as identity of the user responsible for producing the message. From RabbitMQ: If this property is set by a publisher, its value must be equal to the name of the user used to open the connection (i.e. validation occurs to ensure it is the connected/authenticated user). If the user-id property is not set, the publisher's identity remains private.
• appId(RabbitMQ XML type="shortstr"; java type="String"): Optional. For application use, no formal (RabbitMQ) behaviour. The creating application id. Can be populated by producers and read by consumers. (Looking at R-MQ server code, this is not used at all by the server, although the "webmachine-wrapper" plugin provides a script and matching templates to create a webmachine - where an admin can provide an appId to the script.)
• cluster Id(RabbitMQ XML type="N/A"; java type="String"): Deprecated in AMQP 0.9.1 - i.e. not used.In previous versions, was the intra-cluster routing identifier, for use by cluster applications, which should not be used by client applications (i.e. not populated). However, this has been deprecated and removed from the current schema and is not used by R-MQ server code.

• 内容类型（AMQP XML 类型=“shortstr”；java 类型=“字符串”）：可选。消息的应用程序数据部分（正文）的 RFC-2046 MIME 类型。可以包含定义使用的字符编码的字符集参数：例如，'text/plain; 字符集=“utf-8”'。当内容类型未知时，不应设置内容类型，允许接收者确定实际类型。如果该部分已知为真正不透明的二进制数据，则内容类型应设置为 application/octet-stream。
• 内容编码(AMQP XML type="shortstr"; java type="String")：可选。当存在时，描述应用于应用程序数据的附加内容编码，因此需要应用什么解码机制才能获得内容类型头字段引用的媒体类型。主要用于允许在不丢失其底层内容类型标识的情况下压缩文档。内容类型的修饰符，按照 RFC 2616 的第 3.5 节解释。有效的内容编码在 IANA 注册。实现不应该使用压缩编码，除非保持与最初使用其他协议发送的消息兼容，例如 HTTP 或 SMTP。实现不应该指定多个内容编码值，除非与最初使用其他协议发送的消息兼容，例如 HTTP 或 SMTP。
• 标头（AMQP XML type="table"；java type="Map"）：可选。应用程序指定的标头参数及其值列表。这些可以设置为仅供应用程序使用。此外，还可以使用“Header Exchange Type”创建队列——当创建队列时，会给出一系列要匹配的标题属性名称，每个名称都有要匹配的可选值，以便通过标题路由到此队列-匹配。
• DeliveryMode(RabbitMQ XML type="octet"; java type="Integer")：1（非持久）或2（持久）。仅适用于实现持久性的队列。持久消息安全地保存在磁盘上，即使出现严重的网络故障、服务器崩溃、溢出等，也能保证被传递。
• priority(AMQP XML type="octet"; java type="Integer")：相对消息优先级（0 到 9）。高优先级消息是[可能是？？- GB] 在同一消息队列中等待的较低优先级消息之前发送。当必须丢弃消息以维持特定服务质量级别时，服务器将首先丢弃低优先级消息。仅适用于实现优先级的队列。
• 相关性 ID（AMQP XML 类型 =“八位字节”；java 类型 =“字符串”）：可选。对于应用程序使用，没有正式的 (RabbitMQ) 行为。可用于标记或标识客户端之间的消息的特定于客户端的 ID。
• 回复（AMQP XML 类型 =“shortstr”；java 类型 =“字符串”）：可选。对于应用程序使用，在请求消息中使用时，没有正式的 (RabbitMQ) 行为，但可能包含私有响应队列的名称。要发送回复的节点的地址。
• 到期（AMQP XML 类型=“shortstr”；java 类型=“字符串”）：可选。(3) 中的RabbitMQ AMQP 0.9.1 模式声明“为了实现使用，没有正式的行为”。(2) 中的 AMQP 0.9.1 模式 pdf 规定了该消息被视为过期的绝对时间。但是，必须忽略这两个描述，因为此 TTL 链接和客户端/服务器代码表明以下情况为真。从客户端，到期只能通过 BasicProperties 的自定义应用程序初始化来填充。在服务器上，这用于在排队之前从服务器收到消息的点确定 TTL。服务器选择 TTL 作为 (1) 消息 TTL 的最小值（客户端BasicProperties 过期作为相对时间（以毫秒为单位）和（2）队列 TTL（以毫秒为单位配置的x-message-ttl）。格式：字符串引用整数表示毫秒数；服务器收到消息后的到期时间。
• 消息 ID（AMQP XML 类型 =“shortstr”；java 类型 =“字符串”）：可选。对于应用程序使用，没有正式的 (RabbitMQ) 行为。如果设置，消息生产者应将其设置为全局唯一值。将来（AMQP 1.0），如果 message-id 的值与先前收到的发送到同一节点的消息的值匹配，则代理可以将消息作为副本丢弃。
• 时间戳（AMQP XML type="timestamp"; java type="java.util.Date"）：可选。对于应用程序使用，没有正式的 (RabbitMQ) 行为。创建此消息的绝对时间。
• type(AMQP XML type="shortstr"; java type="String")：可选。对于应用程序使用，没有正式的 (RabbitMQ) 行为。[将消息描述为属于/属于特定于应用程序的“类型”或“表单”或“业务交易” - GB]
• userId(AMQP XML type="shortstr"; java type="String")：可选。XML Schema 声明“对于应用程序使用，没有正式的（RabbitMQ）行为” - 但我相信这在最新版本中已经改变（继续阅读）。如果设置，客户端将此值设置为负责生成消息的用户的身份。来自RabbitMQ：如果此属性由发布者设置，则其值必须等于用于打开连接的用户名（即进行验证以确保它是已连接/经过身份验证的用户）。如果未设置 user-id 属性，则发布者的身份将保持私密。
• appId(RabbitMQ XML type="shortstr"; java type="String")：可选。对于应用程序使用，没有正式的 (RabbitMQ) 行为。创建应用程序 ID。可以由生产者填充并由消费者读取。（查看 R-MQ 服务器代码，服务器根本不使用它，尽管“webmachine-wrapper”插件提供了一个脚本和匹配的模板来创建一个 webmachine - 管理员可以为脚本提供一个 appId。）
• 集群 ID（RabbitMQ XML type="N/A"；java type="String"）：在 AMQP 0.9.1 中已弃用 - 即未使用。在以前的版本中，是集群内路由标识符，供集群应用程序使用，不应由客户端应用程序使用（即未填充）。但是，这已被弃用并从当前模式中删除，并且未被 R-MQ 服务器代码使用。

As you can see above, the vast majority of these properties do not have enumerated / constrained / recommended values because they are "application use only" and are not used by RabbitMQ. So you have an easy job. You're free to write/read values that are useful to your application - as long as they match datatype and compile :). ContentTypeand contentEncodingare as per standard HTTP use. DeliveryModeand priorityare constrained numbers.

正如您在上面看到的，这些属性中的绝大多数没有枚举/约束/推荐值，因为它们“仅供应用程序使用”并且不被 RabbitMQ 使用。所以你的工作很轻松。您可以随意写入/读取对您的应用程序有用的值 - 只要它们匹配数据类型并编译 :)。 ContentType并且contentEncoding按照标准 HTTP 使用。 DeliveryMode并且priority是受约束的数字。

Note: Useful, but simple constants for AMQP.BasicProperties are available in class MessageProperties.

注意： AMQP.BasicProperties 有用但简单的常量在MessageProperties类中可用。

Cheers :)

干杯:)

UPDATE TO POST:

更新发布：

With many thanks to Renat (see comments), have looked at erlang server code in rabbit_amqqueue_process.erl and documentation at RabbitMQ TTL Extensions to AMQP. Message expiration (time-to-live) can be specified

非常感谢 Renat（见评论），查看了 rabbit_amqqueue_process.erl 中的 erlang 服务器代码和RabbitMQ TTL Extensions to AMQP 中的文档。可以指定消息过期时间（time-to-live）

• per queue via:

  Map<String, Object> args = new HashMap<String, Object>();
  args.put("x-message-ttl", 60000);
  channel.queueDeclare("myqueue", false, false, false, args);
  

• or per message via:

  byte[] messageBodyBytes = "Hello, world!".getBytes();
  AMQP.BasicProperties properties = new AMQP.BasicProperties();
  properties.setExpiration("60000");
  channel.basicPublish("my-exchange", "routing-key", properties, messageBodyBytes);
  

• 每个队列通过：

  Map<String, Object> args = new HashMap<String, Object>();
  args.put("x-message-ttl", 60000);
  channel.queueDeclare("myqueue", false, false, false, args);
  

• 或每条消息通过：

  byte[] messageBodyBytes = "Hello, world!".getBytes();
  AMQP.BasicProperties properties = new AMQP.BasicProperties();
  properties.setExpiration("60000");
  channel.basicPublish("my-exchange", "routing-key", properties, messageBodyBytes);
  

Here, the ttl/expiration is in millisecs, so 60 sec in each case. Have updated above definition of expirationto reflect this.

这里，ttl/expiration 以毫秒为单位，所以在每种情况下都是 60 秒。更新了上述过期定义以反映这一点。