測試中心在前幾周發現客戶端到ActiveMQ的連接建立了超過6W個，且都是Establish狀態，導致了火墻的CPU飆高到了99%。主要問題是客戶端上并沒有使用重連連接的邏輯，唯一重連連接的可能就是failover了，但是failover也只是在連接斷開后才會進行連接的重建。
因此唯一的可能指向了應用上認為連接斷開了，但是系統端的連接實際上并未斷開。進一步考慮生產和測試的差異，最大可能是因為MQ的數量太少，導致MQ上負載過大。由于每個客戶端建立兩個連接，中心一共有6000個客戶端，而只有4臺4C8G的MQ，暨每個MQ需要承載3000個連接。
呵呵噠……
為了具體定位問題的原因，需要在測試中心重現一下問題，然后拿日志來分析原因。
接著開始漫長的扯皮過程。
測試中心：你不定位問題原因，不能讓你開MQ
我：不開MQ我怎么定位問題原因…日志都被沖掉了。（ActiveMQ默認日志是1MB，滾動5次）
測試中心：我這一堆應用，如果再出問題怎么辦？
我：這次在網絡側監控著，如果連接數超過了預期，那就立刻用殺進程的方式關閉MQ就行。
測試中心：……
一周后
我：哈嘍，上次的方案可行嗎？有空看看嗎？
測試中心：……
一周后
測試中心：你提個變更申請吧
提完變更申請
測試中心：你這變更可能影響很多業務，我給你把申請退回去，你把應急預案，變更步驟什么的補充下，然后我們來開個會討論一下。
……
皮球踢得漂亮
