Artifactory 7.38.10无法解析Helm Charts超时修复方案

该故障为Artifactory 7.38.x版本系列的已知异步工作队列死锁缺陷，你当前使用的7.38.10 rev 73810900正好处于受影响版本区间：

• 缺陷位于AsyncWorkQueueServiceImpl的任务调度锁逻辑：当Helm虚拟仓库聚合的上游仓库数量较多、或短时间内存在大量Chart上传/拉取操作触发元数据重算时，工作线程会出现锁竞争死锁，元数据计算任务无法被正常消费。从日志可见Helm虚拟元数据积压量持续上涨、其余包类型（Docker/Maven/Conan/Npm）的元数据任务数长期无变化，是任务队列完全阻塞的典型特征。
• 队列阻塞后会逐步占满Artifactory的Web请求处理线程池，新增的Helm仓库索引更新、Chart拉取请求长时间无响应，客户端主动断开连接即触发日志中Client Closed Request 499: java.io.IOException: Broken pipe报错，最终表现为Helm仓库更新超时、应用部署失败。
• 重启可临时清空内存积压任务、重置线程锁状态，因此能短暂恢复服务，但触发条件满足后故障会再次复现，无法根治。

按落地优先级排序：

• 版本升级（根治方案）
  直接升级至Artifactory 7.39.4及以上稳定版本，官方在7.39.x版本分支中已修复异步工作队列的锁竞争逻辑，修复后元数据任务不会出现无限制积压、死锁问题。
• 暂无法升级时的参数规避方案
  在Artifactory配置文件artifactory.system.properties中新增/调整以下参数，配置完成后滚动重启服务生效：

  # 提升异步工作队列核心线程数，默认值偏小易触发积压
  artifactory.async.work.queue.core.pool.size=20
  # 开启异步任务超时自动释锁机制，避免长时间死锁
  artifactory.async.work.queue.task.timeout.minutes=10
  # 关闭非必要的元数据变更实时递归计算，降低队列负载
  artifactory.virtual.repo.metadata.calculate.recursively.on.change=false
  

• 日常运维优化
  • 定期清理Helm虚拟仓库下无效的聚合仓库配置，缩小元数据计算范围
  • 避免业务高峰期批量上传大量Helm Chart，削平元数据计算请求峰值
  • 配置异步队列任务数监控告警，积压量超过100时提前介入，避免故障扩散

注：参数调整为临时规避手段，高负载场景下仍存在积压风险，优先选择版本升级实现彻底修复。

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