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

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

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

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