ActiveMQ故障轉移傳輸 - 爲什麼有這麼多的連接？

我們有4個ActiveMQ代理（每個在獨立服務器上運行）在代理網絡中設置。有大約60個生產者。生產者使用JDNI從Glassfish中查找ActiveMQ連接工廠。ActiveMQ故障轉移傳輸 - 爲什麼有這麼多的連接？

的ActiveMQ的URI在Glassfish的配置如下：

failover:(tcp://phxgapm01:61616,tcp://phxgapm02:61616,tcp://phxgapm03:61616,tcp://phxgapm04:61616)?randomize=true&backup=false&maxReconnectAttempts=8

每個生產者過程將執行javax.jms.ConnectionFactory的JNDI查找，然後創建1個javax.jms.Connection。在生產者運行時，它會定期創建一個javax.jms.Session和javax.jms.MessageProducer，將一些消息發送到一個隊列，然後關閉Session和MessageProducer。

這就是所有的背景 - 現在我的問題。從一些，但不是所有的生產商，我們將看到日誌輸出流類似如下：

2014-12-30 21:07:06,534 INFO FailoverTransport - Successfully connected to tcp://phxgapm03:61616 - [ActiveMQ Task-1] 
2014-12-30 21:07:06,538 INFO FailoverTransport - Successfully connected to tcp://phxgapm04:61616 - [ActiveMQ Task-1] 
2014-12-30 21:07:06,544 INFO FailoverTransport - Successfully connected to tcp://phxgapm02:61616 - [ActiveMQ Task-1] 
2014-12-30 21:07:06,548 INFO FailoverTransport - Successfully connected to tcp://phxgapm04:61616 - [ActiveMQ Task-1] 
2014-12-30 21:07:06,552 INFO FailoverTransport - Successfully connected to tcp://phxgapm01:61616 - [ActiveMQ Task-1] 
2014-12-30 21:07:06,556 INFO FailoverTransport - Successfully connected to tcp://phxgapm02:61616 - [ActiveMQ Task-1] 
2014-12-30 21:07:06,561 INFO FailoverTransport - Successfully connected to tcp://phxgapm02:61616 - [ActiveMQ Task-1] 
2014-12-30 21:07:06,565 INFO FailoverTransport - Successfully connected to tcp://phxgapm01:61616 - [ActiveMQ Task-1] 
2014-12-30 21:07:06,568 INFO FailoverTransport - Successfully connected to tcp://phxgapm02:61616 - [ActiveMQ Task-1] 
2014-12-30 21:07:06,572 INFO FailoverTransport - Successfully connected to tcp://phxgapm04:61616 - [ActiveMQ Task-1] 
2014-12-30 21:07:06,577 INFO FailoverTransport - Successfully connected to tcp://phxgapm03:61616 - [ActiveMQ Task-1] 
2014-12-30 21:07:06,581 INFO FailoverTransport - Successfully connected to tcp://phxgapm04:61616 - [ActiveMQ Task-1] 
2014-12-30 21:07:06,586 INFO FailoverTransport - Successfully connected to tcp://phxgapm01:61616 - [ActiveMQ Task-1] 
2014-12-30 21:07:06,590 INFO FailoverTransport - Successfully connected to tcp://phxgapm03:61616 - [ActiveMQ Task-1] 
2014-12-30 21:07:06,594 INFO FailoverTransport - Successfully connected to tcp://phxgapm04:61616 - [ActiveMQ Task-1]

對於一些生產商，我們將看到以下輸出，每10分鐘 - 對於其他人少頻繁。更令人困惑的是，所有這些生產者爲JMS消息傳遞使用相同的代碼 - 因此，雖然生產者在創建會話和消息生成器的頻率方面可能會有所不同，但它們都使用相同的代碼，並且都只創建一個連接對象。

從閱讀文檔，我的理解是故障轉移傳輸將打開一個經紀人的連接（在我們的案例中隨機選擇）。爲什麼我們看到這種連接流（在60ms內與每個經紀人有多個連接）？使用netstat我們可以看到這些連接。這是正常的嗎？如果不是，有什麼建議可能會導致這種情況？

來源

2014-12-31 sceaj

是否使用直接JMS或JMSTemplate等代碼示例很有幫助。有沒有使用PooledConnectionFactory？ –

它是直的JMS - 沒有使用PooledConnectionFactory（至少不是直接） – sceaj

如果有XA連接工廠，那麼您需要使用PooledConnectionFactory，否則它將一直斷開/重新連接。你可以看到連接數量增長的管理主題之一（不記得哪一個） – stringy05

而無需ActiveMQ的記錄等級升高有一定的空間來炒作，而是：

「對其他人來說是不太頻繁」 - 觀察在不同情況下，不同的行爲在這種情況下完全是自然的。如果負載不是完全分佈在實例之間，它們在消息傳遞方面會有不同的表現。試想一下，你的一個節點佔用了90％的觸發輸入，並單獨完成大部分工作。該節點會承受更高的負載，並且會使用與其餘節點完全不同的JMS資源。
「我的理解是，故障轉移傳輸將打開一個經紀人的連接」 - 這是完全正確的。只有在包裝連接工廠要求打開新的物理連接時，故障轉移纔會起作用。在這種情況下，會爲該請求創建恰好一個連接。
「爲什麼我們看到的連接此流」 - 我敢肯定，這是由於其在項目中的緩衝池實現。您可以看到，已經建立了所有經紀人的連接（隨機分佈），同時指示多個新連接請求。

通過在您的應用程序中增加日誌級別，您將能夠確切地看到哪個圖層啓動了此操作以及出於何種原因。可能的原因是：「所有連接都已過期，並且池將minIdleConnection計數恢復爲最小值」; 「應用程序中的某些傳入請求需要大量消息一次發送，因此您的池會創建它們」。

來源

2015-08-18 17:59:09

ActiveMQ故障轉移傳輸 - 爲什麼有這麼多的連接？

回答

相關問題