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

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

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

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