公司做了套由JMS做消息隊列，從JMS取出對象后轉交給RTX服務器發(fā)送RTX消息的機制。
前幾天出現重大BUG：消息不發(fā)送。

經過兩天的測試發(fā)現了癥結所在：
我們通過RTX服務器發(fā)送RTX消息的機制是通過向一個URL后面加參數來實現的，而這個請求URL，在RTX服務器上默認超時時間設置為0，即永不超時，同時此服務器設置的同一個連接兩次發(fā)送消息的最短間隔時間為15毫秒。
因為我們網管的失誤，打開了8012端口，此端口為RTX服務器接收消息的端口，致使開發(fā)環(huán)境中的消息能夠發(fā)送到工作環(huán)境的服務器，使得RTX服務器接收的并發(fā)量出現瞬時過大現象，RTX服務器判斷為DDOS攻擊，因此拒絕服務，此服務器拒絕服務的方式為不返回任何值。
同時，因為設置的超時時間為0，因此后繼的消息因為前面的并未拋出超時異常也未發(fā)送完成，所以積壓在JMS隊列中，造成了消息發(fā)送失敗的現象。

一開始我一直在找JMS的原因，因為曾經在某處看到過JMS服務器并不穩(wěn)定的文章，但是我在測試過程中發(fā)現，JMS還是很強大的，在消息積壓的時候，其隊列中最高曾積壓了4000多條消息，仍然能夠繼續(xù)工作，我使用的是ActiveMQ+Tomcat6.10。

希望能給碰到類似JMS消息積壓現象的朋友一點啟示，從JMS消息不能正常取出入手，或許會有收獲！