问题描述
在使用 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 对象，应在应用生命周期内复用，避免频繁创建/释放。
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
当在复杂的环境中面临问题，格物之道需：浊而静之徐清，安以动之徐生。 云中，恰是如此!
