項目中的Agent分網(wǎng)段訂閱ActiveMQ集群中VLAN.開頭的Topic，但是一直會出現(xiàn)有agent無法收到消息的情況螺男。針對這個現(xiàn)象繁莹，最近幾天都在研究測試，今天有了點眉目粹胯，記錄一下進展蓖柔。
消息的發(fā)送有三個要素，生產(chǎn)者风纠，MQ况鸣，消費者。消費者保持與MQ的長連接竹观，使用consumer.receive方法拉取消息镐捧。目前的現(xiàn)象是生產(chǎn)者日志里記錄了已經(jīng)將消息發(fā)送至MQ了，但是消費者端沒收到臭增。
排查問題思路
檢查消息是否真的發(fā)送至mq懂酱。
方法：通過一個訂閱所有Topic（VLAN.>）的消費者，檢查MQ是否真的收到了消息速址。同時檢查agent是否收到消息玩焰。
結果：消費者顯示MQ的確收到了，但是Agent沒有收到芍锚。由于Agent使用了消息選擇器接收Topic消息昔园，所以需要測試消息選擇器是否可用。
方法：通過下發(fā)十幾個agent并炮，檢查消息選擇器是否可用默刚。
結果：消息選擇器沒有問題。Agent連接是否正常
方法：找網(wǎng)絡的同事一起查
結果：通過tcpdump逃魄，檢查發(fā)現(xiàn)consumer.receive()并不會與服務器產(chǎn)生交互荤西。真是見了鬼了。由于前期我關了MQ上的inactivity monitor，所以agent和mq之間出現(xiàn)了僵死的連接邪锌。Agent端判斷連接正常勉躺，mq上又認為連接斷開了。所以failover機制沒生效觅丰，數(shù)據(jù)無法通信饵溅。
解決方案：開啟broker端的inactivity monitor功能。
此外妇萄，還發(fā)現(xiàn)了Agent在從blobmessage讀取數(shù)據(jù)流的時候蜕企，讀取一半就卡住了。這個問題還要再看看冠句。轻掩。。
寫這個文章的時候懦底，生產(chǎn)同事又打了個電話給我唇牧，現(xiàn)在看到生產(chǎn)的電話就嚇死了啊；稹奋构！幸好只是問個問題壳影。拱层。。
