使用带有Spring JMS和qpid的Azure服务总线消息时标记为延迟的消息

Question

我可以很好地从服务总线订阅接收消息，但当侦听器中发生异常时，似乎最终会将state=Modified和undeliverableHere=true的处置框架发送到服务总线。服务总线的文档说它不支持amqp修改的配置。

消息以服务总线中的延迟状态结束，我不知道如何将消息推回到活动状态。

JMS配置：

@Bean
public ConnectionFactory jmsConnectionFactory(MessageStoreProperties properties) throws UnsupportedEncodingException {
    JmsConnectionFactory connectionFactory = new JmsConnectionFactory(properties.getUrlString());
    connectionFactory.setClientID(clientId);
    connectionFactory.setUsername(properties.getUsername());
    connectionFactory.setPassword(properties.getPassword());
    connectionFactory.setRedeliveryPolicy(redeliveryPolicy());
    return new CachingConnectionFactory(connectionFactory);
}

@Bean
public JmsDefaultRedeliveryPolicy redeliveryPolicy() {
    JmsDefaultRedeliveryPolicy policy = new JmsDefaultRedeliveryPolicy();
    policy.html" target="_blank">setMaxRedeliveries(50);
    return policy;
}

@Bean
public JmsListenerContainerFactory topicContainerFactory(ConnectionFactory connectionFactory) {
    DefaultJmsListenerContainerFactory factory = new DefaultJmsListenerContainerFactory();
    factory.setConnectionFactory(connectionFactory);
    factory.setSubscriptionDurable(true);
    factory.setPubSubDomain(true);
    factory.setSessionAcknowledgeMode(Session.CLIENT_ACKNOWLEDGE);
    return factory;
}

听众：

@JmsListener(destination = "crm-customer-event/subscriptions/test-sub", containerFactory = "topicContainerFactory")
public void receiveCustomerEvent(@Payload ExecutionContextDTO dto) {
    logger.debug("Got payload: " + dto);
    throw new RuntimeException("Oops");
}

以下是我在日志中看到的内容：

消息传输开始

[299309872:1] <- Transfer{handle=0, deliveryId=0, deliveryTag=\x97\x1c\x87\x04\xb7\xea\x86@\xb3n\xbd\x9fg\x81\x00\x11, messageFormat=0, settled=null, more=false, rcvSettleMode=null, state=null, resume=false, aborted=false, batchable=true} (16695) "\x00Sp\xc0\x0a\x05@@p.........

抛出异常，然后JMS在本地重新传递消息50次（为什么这样做？）

之后我看到的下一个amqp协议帧是

[299309872:1] -> Disposition{role=RECEIVER, first=0, last=0, settled=true, state=Modified{deliveryFailed=true, undeliverableHere=true, messageAnnotations=null}, batchable=false}

在我看来，这最后一个处置框架导致消息进入延迟状态。消息上还有一个锁令牌。即使当TTL通过时，消息仍然卡在订阅中，通过RESTAPI戳消息也没有任何帮助。我尝试过解锁它（使用PUT）和删除它（使用DELETE）。我也尝试过用RESTAPI（包括PeekLock和receive和delete变体）来接收它，但看起来它们好像不存在。我在订阅上设置了在过期后自动将消息移动到死信队列的选项，并且它们永远不会移动。

qpid jms中实现ack的代码就在这里，看来库的这一部分不应该被扩展，否则我将创建自己的实现来返回不同的ack。

如何获得qpid/JMS

1. 使用失败的确认而不是修改的\u失败的\u无法送达的确认
2. 清除那些延迟的消息

Answer 1

首先，JMS规范正确地指出，从MessageListener回调引发异常实际上是一个应用程序编程错误，您的应用程序应该自己处理这些错误。

第二，客户端正在使用正确的配置来指示消息未能传递到此客户端，远程应该支持AMQP 1.0规范中概述的所有配置，我会联系微软并要求他们更紧密地实现该规范。

为了解决上述两个问题，您可以在客户端确认模式下接收消息，当您截获抛出的异常时，您可以使用本JIRA问题中描述的机制配置消息确认。

代码看起来像下面这样：

message.setIntProperty("JMS_AMQP_ACK_TYPE", 2);
message.acknowledge();

其中，模式定义为：

ACCEPTED = 1;
REJECTED = 2;
RELEASED = 3;
MODIFIED_FAILED = 4;
MODIFIED_FAILED_UNDELIVERABLE = 5;