4.0 版的變更
4.0 版的新功能
- MasterSlave 提供對經紀人的持續可用性和容錯能力的支持，使其能夠處理災難性的硬體故障，並且不會遺失訊息（或產生重複訊息）。
- 新的獨佔消費者功能允許您將訊息處理固定到消費者集群中的單個消費者。
- 新的訊息群組功能允許您在多個消費者之間進行訊息負載平衡，同時也保證訊息群組內訊息的順序。
- 新的總排序功能，允許主題上的所有消費者以相同的順序查看訊息。
- 新的JMX 管理和監控功能。 您現在可以查看每個經紀人、目的地、連接器和連線的統計資料！
- 改進的安全性外掛程式，為身份驗證提供 JAAS 支持，以及可插拔的授權策略和預設的基於 XML 的實作。
- 現在提供新的OpenWire C 客戶端。 此客戶端使用與標準 Java 客戶端相同的線路協議，因此 Java 客戶端可用的每個訊息經紀人功能都可供 C 客戶端使用。
- 一個實驗性的OpenWire dotNet可用，它以純 C# 編寫，並提供類似 JMS 的 API，用於在 .Net 平台上使用 ActiveMQ Classic
- 現在可以載入具有持久訊息的佇列，而不會鎖定經紀人。 當沒有消費者很快需要時，持久訊息現在會從記憶體中換出。
- 新的消費者優先級功能允許您透過為消費者分配優先級來建立位置親和性。 然後，經紀人可以在將訊息分派給較低優先級的消費者之前，先將訊息分派給較高優先級的消費者。
- 每個消費者分派異步標誌都可配置，允許您配置經紀人如何將訊息傳送給消費者。 這控制了經紀人是使用 SEDA 還是 STP 樣式分派。
- 新的可插拔主題訂閱恢復策略，允許您配置在建立追溯消費者時重新播放的暫時訊息數量。
- 新的追溯消費者功能允許主題消費者「回到過去」，以便在啟動訂閱時接收舊訊息。 如果消費者是持久消費者，他會恢復仍然在持久儲存中的所有訊息。
- 每個目的地策略允許您配置目的地的行為。
- 經紀人現在支援每個目的地的可插拔分派策略，以便您可以選擇用於將訊息傳送給消費者的分發演算法。
- 經紀人現在支援兩種新的連接器類型
- 慢速消費者處理允許您為非持久主題上的慢速消費者捨棄舊訊息，以避免減慢快速消費者的速度
- 您現在可以指定目的地選項，允許您擴展消費者的配置。
- 預設情況下，消費者現在使用優化確認，這會提高效能。
API/組態變更
- 作為遷移到 Apache 的一部分，套件名稱現在為 org.apache.activemq，而不是 org.activemq。
- XML 組態已稍微變更； 大部分現在都在 ActiveMQ Classic 命名空間中，並具有產生的 XSD 和文件。
- 可靠傳輸已重新命名為 容錯移轉，以使其更清楚其作用； 我們正在開發單獨的 DR 機制以提供資料中心復原能力。 因此，如果您希望連線到多個 URI 中的一個，請嘗試
failover:tcp://host1:port1,tcp://host2:port2 - 傳輸的組態選項已變更。 請參閱ActiveMQ Classic 連線 URI以取得所有選項的詳細指南。
- Spring 套件已移除； 我們現在使用 XBean 來組態 ActiveMQ Classic。 如果您想要在一般 Spring 中使用 Factory Bean 而不是 org.activemq.spring.BrokerFactoryBean，請參閱 org.activemq.xbean.BrokerFactoryBean。 請參閱組態經紀人以取得有關新 XML 語法的更多資訊。
- ActiveMQTopic 和 ActiveMQQueue 現在位於 org.activemq.command 套件中。
- 如果您在 Java 程式碼中建立經紀人，則 BrokerContainer 已被更容易使用的 BrokerService 取代。
- 連線 URL 選項已稍微變更，以提供更精確的傳輸和線路格式組態選項，並允許驗證選項。
- 訊息重新傳遞和 DLQ 處理已重新實作。 目前，所有傳送毒訊息的訊息都會傳送到單一 DQL。
- JMS 串流 API 已變更。
一般變更
- JDBC 持久性介面卡現在使用 JDBC 語句批次處理來提高其與資料庫的效能。 這應該減少檢查點所需的時間。
- QueueBrowsers 現在可以很好地處理目前正在使用的佇列。 它為您提供建立瀏覽器時佇列的真實快照，並且不會影響將訊息分派給活動消費者。
- 我們不再有手工製作的編組程式碼； 它們都基於 OpenWire，並且是從 org.activemq.command 套件中的 Open Wire 命令自動產生的
- 用於經紀人對經紀人訊息傳遞的網路橋接器現在使用較低層級的 ActiveMQ Classic 命令和傳輸 API 而不是 JMS API，這使它們可以使用更多最佳化，並且每個橋接器的資源消耗更低，同時讓 JMS 用戶端 API 實作減少其複雜性。
- 現在支援兩種網路橋接器類型
- 簡單的轉發橋接器 - 盡快將所有訊息傳送給遠端經紀人。 非常適合您預先知道使用模式，並且總是想要執行儲存並轉發到中央經紀人。
- 基於需求的轉發橋接器（與 ActiveMQ Classic 3.x 中使用的橋接器類型相同），它會偵測遠端經紀人上的消費者需求，並僅在需要時轉發訊息。
- 基於需求的轉發橋接器現在會利用消費者優先級來避免將訊息轉發給遠端經紀人，如果本地消費者正在使用其訊息。
- 不再執行訊息片段化。 當您引入經紀人網路時，片段化訊息會增加另一個複雜程度。 大型物件/串流應使用 JMS 串流進行傳輸。
- JMS 用戶端在回滾時會在線路上編組較少的訊息。
- 關閉會話/消費者/生產者時，JMS 用戶端會編組較少的訊息。
- 用戶端和經紀人更廣泛地使用執行緒集區來避免配置未使用的閒置執行緒。
