对于最新的稳定版本,请使用 Spring Integration 6.5.1! |
AMQP 消息头
概述
Spring Integration AMQP 适配器会自动映射所有 AMQP 属性和标头。
(这是对 4.3 的更改 - 以前,仅映射标准标头)。
默认情况下,这些属性被复制到 Spring Integration 或从 Spring Integration 复制MessageHeaders
通过使用DefaultAmqpHeaderMapper
.
您可以传入自己的 AMQP 特定标头映射器的实现,因为适配器具有支持这样做的属性。
AMQP 中的任何用户定义的标头MessageProperties
复制到 AMQP 消息或从 AMQP 消息复制,除非被requestHeaderNames
或replyHeaderNames
属性DefaultAmqpHeaderMapper
.
默认情况下,对于出站映射器,没有x-*
标头被映射。
有关原因,请参阅本节后面出现的警告。
要覆盖默认值并恢复到 4.3 之前的行为,请使用STANDARD_REQUEST_HEADERS
和STANDARD_REPLY_HEADERS
在属性中。
映射用户定义的标头时,值还可以包含简单的通配符模式(例如thing* 或*thing ) 进行匹配。
匹配所有标头。* |
从 4.1 版本开始,AbstractHeaderMapper
(一个DefaultAmqpHeaderMapper
超类)让NON_STANDARD_HEADERS
为requestHeaderNames
和replyHeaderNames
属性(除了现有的STANDARD_REQUEST_HEADERS
和STANDARD_REPLY_HEADERS
) 来映射所有用户定义的标头。
这org.springframework.amqp.support.AmqpHeaders
class 标识DefaultAmqpHeaderMapper
:
-
amqp_appId
-
amqp_clusterId
-
amqp_contentEncoding
-
amqp_contentLength
-
content-type
(参见这contentType
页眉) -
amqp_correlationId
-
amqp_delay
-
amqp_deliveryMode
-
amqp_deliveryTag
-
amqp_expiration
-
amqp_messageCount
-
amqp_messageId
-
amqp_receivedDelay
-
amqp_receivedDeliveryMode
-
amqp_receivedExchange
-
amqp_receivedRoutingKey
-
amqp_redelivered
-
amqp_replyTo
-
amqp_timestamp
-
amqp_type
-
amqp_userId
-
amqp_publishConfirm
-
amqp_publishConfirmNackCause
-
amqp_returnReplyCode
-
amqp_returnReplyText
-
amqp_returnExchange
-
amqp_returnRoutingKey
-
amqp_channel
-
amqp_consumerTag
-
amqp_consumerQueue
如本节前面所述,使用 的标头映射模式是复制所有标头的常用方法。
但是,这可能会产生一些意想不到的副作用,因为某些 RabbitMQ 专有属性/标头也会被复制。
例如,当您使用联合身份验证时,收到的消息可能具有名为* x-received-from ,其中包含发送消息的节点。
如果将通配符用于入站网关上的请求和回复标头映射,则会复制此标头,这可能会导致联合出现一些问题。
此回复消息可能会联合回发送代理,发送代理可能会认为消息正在循环,因此会静默地删除它。
如果您希望使用通配符标头映射的便利,您可能需要过滤掉下游流中的某些标头。
例如,为了避免复制* x-received-from 标题返回到您可以使用的回复<int:header-filter … header-names="x-received-from"> 在将回复发送到 AMQP 入站网关之前。
或者,您可以显式列出实际要映射的那些属性,而不是使用通配符。
由于这些原因,对于入站消息,映射器(默认情况下)不会映射任何x-* 头。
它也不会映射deliveryMode 到amqp_deliveryMode 标头,以避免该标头从入站消息传播到出站消息。
相反,此标头映射到amqp_receivedDeliveryMode ,未映射到输出上。 |
从版本 4.3 开始,可以通过在模式前面加上!
.
否定模式优先,因此列表(例如STANDARD_REQUEST_HEADERS,thing1,ba*,!thing2,!thing3,qux,!thing1
不映射thing1
(也thing2
也不thing3
).
标准标头加上bad
和qux
被映射。
例如,当 JSON 反序列化逻辑在接收方下游以不同的方式完成时,否定技术可能很有用。
为此,一个!json_*
应为入站通道适配器/网关的标头映射器配置模式。
如果用户定义的标头以! 如果您确实希望映射,则需要使用 转义它,如下所示:\ STANDARD_REQUEST_HEADERS,\!myBangHeader .
名为!myBangHeader 现在已映射。 |
从 5.1 版本开始,DefaultAmqpHeaderMapper 将回退到映射MessageHeaders.ID 和MessageHeaders.TIMESTAMP 自MessageProperties.messageId 和MessageProperties.timestamp 分别,如果相应的amqp_messageId 或amqp_timestamp 出站邮件上不存在标头。
入站属性将映射到amqp_* header 和以前一样。
填充messageId 当消息使用者使用有状态重试时,属性。 |
这contentType
页眉
与其他标头不同,AmqpHeaders.CONTENT_TYPE
前缀不为amqp_
;这允许跨不同技术透明地传递 contentType 标头。
例如,发送到 RabbitMQ 队列的入站 HTTP 消息。
这contentType
header 映射到 Spring AMQP 的MessageProperties.contentType
属性,随后映射到 RabbitMQ 的content_type
财产。
在 5.1 版之前,此标头也映射为MessageProperties.headers
地图;这是不正确的,此外,该值可能是错误的,因为底层 Spring AMQP 消息转换器可能更改了内容类型。
这种变化将反映在头等舱content_type
属性,但不在 RabbitMQ 标头映射中。
入站映射忽略了标头映射值。contentType
不再映射到标头映射中的条目。