我们的应用程序使用主题将消息推送给一小组订阅者。在根据要推送的实际消息的大小建模jms消息时，我应该寻找什么样的东西。是否有任何已知限制或特定于应用程序服务器？关于这个主题的任何最佳实践或建议（双关语意外）？
答案 0 :(得分：4)
在达到技术限制之前，您可能会达到实际限制。也就是说，消息长度可能在长度上有技术限制，可以用int或long表示，但这不太可能是你遇到的第一个约束。
以兆字节为单位的消息长度往往是重量级的。想想几个K就像你想要的球场一样。
有时使用的技术是发送说“项目123435已更新”的小消息，然后消费者从数据库或其他存储机制中检索与项目12345相关联的数据。因此，每个客户端只能获得他们需要的数据，我们不会在订户可能不需要的时候喷洒大量数据。
答案 1 :(得分：3)
我建议您查看预订企业集成模式 ，其中会详尽地分析处理您所询问的问题的许多模式。特别是，如果邮件的大小很大，您可以使用邮件序列来解决问题：
大量数据：有时候 应用程序想真正转移 大数据结构，可能不是 舒适地贴合在一条信息中。 在这种情况下，将数据分成更多 可管理的块并将它们发送为 Message Sequence。大块 必须作为序列发送，而不是 只是一堆消息，所以 接收器可以重建原件 数据结构。
引自http://www.eaipatterns.com/MessageConstructionIntro.html
有关本书每种模式简要说明的主页，请访问http://www.eaipatterns.com/index.html
答案 2 :(得分：0)
具体实施。正如您所料，越小越好。例如，Tibco建议将邮件大小保持在100 KB以下。
答案 3 :(得分：0)
显然，小消息更快。话虽如此，底层的JMS服务器实现可以使用例如消息压缩来提高性能，例如Weblogic 9.（http://download.oracle.com/docs/cd/E13222_01/wls/docs92/perform/jmstuning.html#wp1150012）