ActiveMQ Artemis：如何排查阻塞的TLS acceptor问题？

1. 提升日志级别捕获底层细节 #

当前INFO级别日志无法覆盖TLS握手阶段的核心交互，临时调整logging.properties获取关键信息：

# 修改核心服务器日志级别
logger.org.apache.activemq.artemis.core.server.level=DEBUG
# 添加远程通信模块日志
logger.org.apache.activemq.artemis.core.remoting.level=DEBUG
# 添加Netty底层日志（适配Artemis默认通信框架）
logger.io.netty.level=DEBUG

注意：DEBUG日志量较大，仅在问题复现期间开启，排查完成后恢复原配置。

2. 检查连接资源是否耗尽 #

• 用Artemis CLI查看当前活跃连接数，对比connectionsAllowed=10000的配置上限：

  ./artemis connection list
  

• 用系统命令查看端口61617的TCP连接状态，重点关注未正常释放的连接：

  ss -antp | grep :61617
  

  若存在大量TIME_WAIT或ESTABLISHED状态的僵死连接，可能导致acceptor无法处理新请求。

3. 排查多协议混合支持的冲突 #

artemis-tls同时启用了多种协议，而其他正常的TLS acceptor仅支持单一协议，尝试缩小范围验证：

• 临时修改artemis-tls的protocols参数，仅保留CORE协议：

  <acceptor name="artemis-tls">tcp://0.0.0.0:61617?tcpSendBufferSize=1048576;tcpReceiveBufferSize=1048576;amqpMinLargeMessageSize=102400;protocols=CORE;useEpoll=true;amqpCredits=1000;amqpLowCredits=300;amqpDuplicateDetection=true;sslEnabled=true;keyStorePath=/var/lib/artemis/certs/keystore.jks;keyStorePassword=${keyStorePassword};enabledProtocols=TLSv1.2,TLSv1.3</acceptor>
  

  重启后观察问题是否复现，排查是否是某类协议客户端触发阻塞。
• 临时禁用TLSv1.3，仅保留TLSv1.2，排查版本协议协商的潜在bug：

  enabledProtocols=TLSv1.2
  

4. 验证epoll配置的兼容性 #

• 临时将useEpoll=true改为useEpoll=false，切换到NIO模式，重启后观察问题是否消失，排查epoll实现的底层bug。
• 尝试移除tcpSendBufferSize和tcpReceiveBufferSize参数，使用系统默认缓冲区配置，避免手动配置不匹配导致的阻塞。

5. 确认密钥库的可用性 #

• 检查密钥库文件权限，确保Artemis运行用户拥有读取权限：

  ls -l /var/lib/artemis/certs/keystore.jks
  

• 用keytool验证密钥库的有效性，确认证书未过期、密钥与证书匹配：

  keytool -list -v -keystore /var/lib/artemis/certs/keystore.jks
  

6. 尝试升级到稳定版本 #

ActiveMQ Artemis v2.19.1是2021年发布的旧版本，存在大量已修复的TLS和连接管理相关bug，建议升级到最新2.x稳定版（如v2.32.0）验证问题是否解决。

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