我正在开发一个将大量使用JBoss消息传递（JMS）的项目。我的任务是为其他开发人员构建一个易于使用的消息传递包装器，并且正在考虑使用JMS的消息选择器来提供一种过滤技术，以将不必要的消息发送保持在最低限度。我很好奇是否有人在性能方面有任何经验？我担心的是，JMS提供商可能会陷入消息选择器的困境，从而有效地破坏整个目的。但是，这比为每个消息类型创建一长串主题/队列要好得多。
最终，我最终会使用两者的某种组合，但我担心的是无论我更倾向于哪种方式，都会对性能产生影响。
正如 Martin 所提到的，默认情况下，大多数 JMS 实现将在客户端上处理消息选择器，除非它们是持久订阅的一部分，当大多数 JMS 实现也会在服务器上处理它们时，以避免当通过选择器的消息数量显著减少时，会持久化太多消息。某些系统（如 SonicMQ）允许您指定应在服务器上处理消息选择器，这在消息代理上有过多的 CPU 可用但使用者不可用的情况下，这是一个不错的选择。
请记住，虽然基于主题的选择通常更快，但它可能非常麻烦，因为如果你想听5个不同的东西，你必须有5个不同的MessageConsumers。在朴素的驱动程序实现中，每个线程都是不同的线程，并且可能会开始累积。因此，从发布中同时支持这两个主题通常很有用，这样某些客户端就可以只收听他们想要的主题，而其他客户端可以使用消息选择器（或基于代码的选择器）来收听他们想要的主题层次结构（例如 foo.#）。
但是，应始终针对应用程序和代理进行测试。每个代理以不同的方式处理情况，每个应用程序的功能也不同。您不能只说“始终使用技术 X”，因为客户端导向消息处理的每种技术都有不同的权衡。基准，基准，基准。
使用消息选择器要记住的一件事是，它们不是动态可更改的，因此您可能会丢失消息或必须手动管理复杂的切换方案。想象一下以下用例：
我的两分钱：
我问自己关于ActiveMQ的问题完全相同。
我确实开发了一个抽象层，允许开发人员在不提出问题的情况下进行编码，我们通过切换实现进行了测试。
