4.0 中的更改

功能 > 新功能 > 4.0 中的更改

4.0 中的新功能

MasterSlave 提供了对代理的持续可用性和容错的支持，以处理灾难性的硬件故障，并且不会丢失任何消息（或出现重复）。
新的独占消费者功能允许您将消息处理固定到消费者集群中的单个消费者。
新的消息组功能允许您在消费者集之间负载平衡消息，但同时还保证消息组中消息的顺序。
新的完全排序功能，允许主题上的所有消费者以相同的顺序查看消息。
新的 JMX 管理和监控功能。您现在可以查看每个代理、目的地、连接器和连接的统计信息！
改进的安全插件，它提供 JAAS 支持以进行身份验证，以及可插入的授权策略，以及默认的基于 XML 的实现。
新的 OpenWire C 客户端现已推出。该客户端与标准 Java 客户端使用的相同线协议通信，因此 Java 客户端可用的每个消息代理功能都可用于 C 客户端。
实验性的 OpenWire dotNet 可用，它使用纯 C# 编写，以及用于在 .Net 平台上使用 ActiveMQ Classic 的类似 JMS 的 API
队列现在可以加载持久消息而不会锁定代理。持久消息现在会在没有消费者需要它时从内存中交换出去。
新的消费者优先级功能允许您通过为消费者分配优先级来构建位置亲和性。然后代理可以在将消息分派给较低优先级消费者之前，将消息分派给较高优先级消费者。
可配置的每个消费者分派异步标志，它允许您配置代理如何将消息发送给消费者。这控制代理是否使用 SEDA 或 STP 样式分派。
新的可插入的主题订阅恢复策略，它允许您配置创建追溯消费者时重播多少个瞬态消息。
新的追溯消费者功能允许主题消费者“回到过去”，以便在订阅激活时接收旧消息。如果消费者是持久消费者，他将恢复持久存储中仍存在的全部消息。
每个目的地策略允许您配置目的地的行为。
代理现在支持每个目的地可插入的分派策略，以便您可以选择用于将消息发送给消费者的分发算法。
代理现在支持两种新的连接器类型
- JMS 连接器用于建立与外部 JMS 提供程序的连接，以便可以在系统之间桥接消息。
- 代理连接器。用于将连接代理到另一个代理。
慢速消费者处理允许您丢弃非持久主题上的慢速消费者的旧消息，以避免减慢快速消费者的速度
您现在可以指定目的地选项，允许您扩展消费者的配置。
Conumsers 现在默认情况下使用优化确认，这会导致性能提高。

API/配置更改

作为迁移到 Apache 的一部分，包名称现在是 org.apache.activemq 而不是 org.activemq。
the Xml 配置已经发生了一些变化；主要是它现在位于 ActiveMQ Classic 命名空间中，并具有生成的 XSD 和文档。
the reliable 传输已重命名为 failover，以使其更清楚地表明其作用；我们正在开发一个单独的 DR 机制来提供数据中心弹性。因此，如果您希望连接到多个 URI 之一，请尝试
```
failover:tcp://host1:port1,tcp://host2:port2
```
传输的配置选项已更改。有关所有选项的详细指南，请参阅 ActiveMQ Classic 连接 URI。
spring 包已消失；我们现在使用 XBean 来配置 ActiveMQ Classic。如果您想要在常规 spring 中使用的工厂 bean，而不是 org.activemq.spring.BrokerFactoryBean，请参阅 org.activemq.xbean.BrokerFactoryBean。有关新 XML 语法的更多信息，请参阅配置代理。
ActiveMQTopic 和 ActiveMQQueue 现在位于 org.activemq.command 包中。
如果您正在 Java 代码中创建代理，BrokerContainer 已被 BrokerService 替换，现在更易于使用。
连接 URL 选项略有变化，以提供更精确的传输和线格式的配置选项，并允许验证选项。
消息重新传递和 DLQ 处理已经重新实现。目前，所有发送的毒性消息都被发送到单个 DQL。
the 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 客户端在会话/消费者/生产者关闭时编组更少的消息。
客户端和代理更广泛地使用线程池，以避免分配未使用的空闲线程。