Azure Event Hub连接关闭报错含义及正确处理方案咨询

错误本质说明 #

你遇到的报错：

Error{condition=amqp:connection:forced, description='The connection was inactive for more than the allowed 300000 milliseconds and is closed by container 'LinkTracker'. TrackingId:00000000000000000000000000000000000_G21, SystemTracker:gateway5, Timestamp:2019-03-06T17:32:00', info=null}

属于非严重性的连接回收通知，并非业务故障。你观测到事件发送成功是因为新的发送请求会自动触发SDK重建AMQP连接与链路，业务数据不会丢失，报错仅代表超过5分钟无活动的旧空闲连接被服务端主动关闭。

对应处理方案 #

你可以根据自身的事件发送频率选择合适的处理方式：

场景1：高频率/批量发送事件 #

如果需要持续、大量发送事件，推荐复用EventHubProducerClient单例，不需要每次发送后调用close()：

• 官方SDK已经内置了连接池、链路自动重建的优化逻辑，全局复用单例可以平摊实例创建的开销（包括TCP握手、AMQP链路协商、权限校验等），性能远高于每次新建实例。
• 如果发送存在间歇性，间隔时间接近5分钟，可以主动增加心跳逻辑：每4分钟左右发起一次轻量请求（比如获取Event Hub运行时元数据、发送空的批量事件），保持链路活跃，避免服务端回收连接产生报错。

场景2：低频率/零散发送事件 #

如果发送间隔很长（比如数小时才发送一次事件），可以选择每次发送完成后调用close()关闭实例：

• 该场景下新建实例的性能开销占比极低，还可以避免空闲连接被回收产生的冗余报错日志。
• 单实例的创建耗时通常在百毫秒级别，内存占用不足1MB，只要不是每秒级别的频繁创建销毁，不会产生性能问题。

注意事项 #

禁止在高频发送场景下频繁创建销毁EventHubProducerClient实例，反复的TCP连接建立、AMQP链路协商会增加发送延迟，严重时还可能触发Event Hub服务端的限流规则。

内容的提问来源于stack exchange，提问作者once