终于找到ActiveMQ无响应的罪魁祸首了

罪魁祸首了"/>

终于找到ActiveMQ无响应的罪魁祸首了

今天终于找到ActiveMQ用了一段时间后无响应的原因了。

ActiveMQ默认配置里面最大连接数为1000个，在activemq.xml中的配置：

<!--The transport connectors expose ActiveMQ over a given protocol toclients and other brokers. For more information, see:.html--><transportConnectors><!-- DOS protection, limit concurrent connections to 1000 and frame size to 100MB --><transportConnector name="openwire" uri="tcp://0.0.0.0:61616?maximumConnections=1000&amp;wireFormat.maxFrameSize=104857600"/><transportConnector name="amqp" uri="amqp://0.0.0.0:5672?maximumConnections=1000&amp;wireFormat.maxFrameSize=104857600"/><transportConnector name="stomp" uri="stomp://0.0.0.0:61613?maximumConnections=1000&amp;wireFormat.maxFrameSize=104857600"/><transportConnector name="mqtt" uri="mqtt://0.0.0.0:1883?maximumConnections=1000&amp;wireFormat.maxFrameSize=104857600"/><transportConnector name="ws" uri="ws://0.0.0.0:61614?maximumConnections=1000&amp;wireFormat.maxFrameSize=104857600"/></transportConnectors>

一个子系统（.NET 5 WebApi 采用Apache.NMS.ActiveMQ库）在处理业务时不停的创建到ActiveMQ的连接，却并没有主动去关闭连接，导致连接数达到ActiveMQ的上限，从而拒绝新的连接。表现现象是系统无响应，抛出ActiveMQ的错误。

之前出现过几次，因为生产系统，大家都比较急，没有仔细去看日志去查找问题根源，以为是ActiveMQ哪里没有配好，直接重新启动ActiveMQ，重新启动各个子系统，第一时间恢复业务。

今天找到问题后，立马将ActiveMQ的连接数设置为10000，先让系统能够正常处理业务。然后改进系统，减少建立ActiveMQ的连接数，且在使用完毕后能够及时Close掉与ActiveMQ的连接。改完后，升级，监控连接数，虽然还是不少，但是浮动的了，说明连接有关闭。

一天监控下来，各个子系统都正常。

不停地建立、关闭ActiveMQ连接是比较消耗资源的，性能也有所下降；后续改进：尽量用长连接来进行ActiveMQ消息通讯。

这个问题这段时间，搞得我寝食难安，百思不得其解；周末也在家里各种测试，想复现生产环境的问题，自己的电脑跑了一天，发了上千万的消息，也没重现。今天总算找到了，心里的一块石头总算落地了，可以睡个安稳觉了！