【Azure Service Bus】Azure Service Bus Java SDK 中 Token 刷新异常的排查思路

问题描述

在使用 Azure Service Bus Java SDK 时，应用日志里偶尔会出现类似下面的告警，且通常是 低频、偶发：

ActiveClientTokenManager:

{\"az.sdk.message\":\"Error occurred while refreshing token that is not retriable. Not scheduling refresh task. Use ActiveClientTokenManager.authorize() to schedule task again.\",

\"exception\":\"Cannot send a message when request response channel is disposed. ConnectionId:MF_c533c8_1772659601664 isCacheTerminated:true isConnectionTerminated:true\",

\"scopes\":\"amqp://xxxxxxxxxxxxxxxxxx.servicebus.chinacloudapi.cn/**************\",

\"audience\":\"amqp://xxxxxxxxxxxxxxxxxx.servicebus.chinacloudapi.cn/**************\"}"

从应用侧观察：

应用已配置重试机制，消息最终 未丢失，收发链路可自行恢复；
日志级别看起来很严重，但业务调用并没有实际失败；
主要困惑在于：
- 这条日志的根本原因是什么？
- 是否属于潜在风险或未来可能放大的问题？
- 是否需要主动修复？

异常发生在 ActiveClientTokenManager 的 Token 刷新逻辑，并伴随 AMQP 连接 / RequestResponseChannel 被释放（disposed / terminated）的状态。

问题解答

SDK（底层 azure-core-amqp）在客户端内部维护两条共用同一 AMQP Connection 的链路：

消息处理链路：应用线程通过 sender / receiver / processor 收发消息；
Client管理链路 ：ActiveClientTokenManager 等组件定时刷新 Token。

当 AMQP 连接因 空闲超时被服务端关闭 / 网络瞬断 / NAT 回收空闲连接 等原因被释放时，后台 Token 刷新任务会在下一次定时触发时撞上「通道已 disposed」状态，于是抛出文章开头那条日志。

SDK 内部判定大致是：Connection.isDisposed() 或 RequestResponseChannelCache.terminated 任一为真 → 当前刷新被标记为 non-retriable → 记 WARN 日志 + 不再为该通道调度下一次刷新。

什么情况下可以忽略这个报错呢？

如果这个日志是低频偶发，并且业务无失败、无延迟突增、消息无丢失。可以视为噪声。

什么情况下不能忽略这个报错呢？

出现以下任一情况，就需要深入调查：

日志高频密集出现（如每分钟数十条且持续）
业务 send / receive 已经超过 maxRetries 仍最终失败
出现吞吐下降、端到端延迟拉长
Service Bus 指标里 ServerErrors / UserErrors / ThrottledRequests 异常上升
日志中混入 amqp:unauthorized-access（这才是真正的认证失效）

解决方法

一：升级到较新的 azure-messaging-servicebus

7.14.x 之后持续改进了 RequestResponseChannelClosedException 路径下 send / createBatch 的重试行为，新版仍在优化连接恢复，详细可参考 : azure-sdk-for-java/sdk/servicebus/azure-messaging-servicebus/CHANGELOG.md at main · Azure/azure-sdk-for-java

二：配置合理的 AmqpRetryOptions，并让客户端长生命周期复用

ServiceBusClientBuilder 创建出的 sender / receiver / processor 对象，应在应用生命周期内复用，避免频繁创建/释放。

cs 复制代码

AmqpRetryOptions retryOptions = new AmqpRetryOptions()
.setMaxRetries(5)
.setMode(AmqpRetryMode.EXPONENTIAL)
.setTryTimeout(Duration.ofSeconds(60));

ServiceBusSenderClient sender = new ServiceBusClientBuilder()
.credential(fullyQualifiedNamespace, new DefaultAzureCredentialBuilder().build())
.retryOptions(retryOptions)
.sender()
.queueName(queueName)
.buildClient();

参考资料

Troubleshoot AMQP errors in Azure Service Bus : https://learn.microsoft.com/zh-cn/azure/service-bus-messaging/service-bus-amqp-troubleshoot

ActiveClientTokenManager 源码: https://github.com/Azure/azure-sdk-for-java/blob/main/sdk/core/azure-core-amqp/src/main/java/com/azure/core/amqp/implementation/ActiveClientTokenManager.java

azure-messaging-servicebus CHANGELOG : https://github.com/Azure/azure-sdk-for-java/blob/main/sdk/servicebus/azure-messaging-servicebus/CHANGELOG.md

当在复杂的环境中面临问题，格物之道需：浊而静之徐清，安以动之徐生。云中，恰是如此!