MDB 和耐久性
为了使持久性有意义，部署 MDB 的应用程序服务器应该与 JMS 提供程序（服务器）分开，这样，如果应用程序服务器关闭并稍后重新启动，则可以向 MDB 发送它所拥有的消息当应用程序服务器关闭时错过了？
For durability to make sense, should the app server in which an MDB is deployed to be separated from the JMS Provider (server), so that if the app server shuts down and is restarted later, the MDB can be sent the messages that it had missed while the app server was down?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
但是，如果服务器从未接受过该消息（因为它也已关闭），则客户端无法认为一切正常，因此不会神秘地丢失任何消息。
但更实际的是，持久性属性确实假设多个远程客户端正在侦听一个主题。如果您的设置是这样的，即您已经在不同的远程服务器上针对某个主题拥有多个侦听器，我想您不会问这个问题。所以我假设您将 MDB 全部部署在一台服务器上。
在这种情况下，分离 JMS 提供程序可以提高鲁棒性，因为仅运行该提供程序的服务器崩溃的风险可能较低（更小的更专用的系统，特别是没有您自己的代码 = 崩溃的可能性较小）并且可以充当缓冲区对于那些必须重新启动应用程序服务器的情况。另一方面，对于每台服务器，至少其中一个服务器崩溃的可能性会增加，并且在某处发生配置错误的可能性也会增加。这是你必须自己做出的权衡。
But if the server never accepted the message (because it too was down) the client can not think everything is okay and so no messages will be mysteriously missed.
More practically though, the durability property indeed assumes a single topic to which multiple remote clients are listening. If your setup is such that you already had multiple listeners on different remote servers for a topic, I guess you wouldn't be asking this question. So I assume you have your MDB(s) all deployed on a single server.
In that case, separating the JMS provider could improve your robustness, as the server running just this provider might have a lower risk to crash (smaller more dedicated system, especially without your own code = less likely to crash) and could function as a buffer for those situations where you have to restart your application server. On the other hand, with each server you add the chance that at least one of them crashes increases and the possibility that you make a configuration error somewhere increases as well. This is a tradeoff you have to make your self.
我会说是的。一种选择是独立部署 HornetQ：
http://docs.jboss.org/hornetq/2.2.5.Final/user-manual/en/html/architecture.html#d0e636
这样您就不需要部署功能齐全的 JBoss 服务器，通过减少主机规格来节省一些资金。独立模式下 HornetQ 的内存占用量可能非常低。
如果拆分 jms 代理和 MDB 客户端不可行，我曾经采用的方法是在客户端中开发一个缓存来保存未发送的消息，这样，如果服务器关闭，它会存储消息，直到 JBoss 再次启动。
I would say yes. One option could be deploying HornetQ standalone:
http://docs.jboss.org/hornetq/2.2.5.Final/user-manual/en/html/architecture.html#d0e636
This way you don't need to deploy a fully featured JBoss server, saving some money by reducing your hosts specs. The memory footprint of HornetQ in standalone mode can be very low.
If splitting jms broker and MDB client is not an option, the way I did it once was developing a cache in the client that keeps unsent messages, so that if the server is down it stores messages until JBoss is up again.
持久性属性更适用于这样的情况：客户端认为一切正常，因为服务器的主题已接受消息，但实际上无法将消息传递给所有预期的接收者，因为其中一个或多个接收者已关闭。
但是，如果服务器从未接受过该消息（因为它也已关闭），则客户端无法认为一切正常，因此不会神秘地丢失任何消息。
但更实际的是，持久性属性确实假设多个远程客户端正在侦听一个主题。如果您的设置是这样的，即您已经在不同的远程服务器上针对某个主题拥有多个侦听器，我想您不会问这个问题。所以我假设您将 MDB 全部部署在一台服务器上。
在这种情况下，分离 JMS 提供程序可以提高鲁棒性，因为仅运行该提供程序的服务器崩溃的风险可能较低（更小的更专用的系统，特别是没有您自己的代码 = 崩溃的可能性较小）并且可以充当缓冲区对于那些必须重新启动应用程序服务器的情况。另一方面，对于每台服务器，至少其中一个服务器崩溃的可能性会增加，并且在某处发生配置错误的可能性也会增加。这是你必须自己做出的权衡。
The durability property is more intended for those situations where the client thinks everything is okay since the server's topic has accepted the message, but then it can not actually be delivered to all intended recipients, since one or more of them were down.
But if the server never accepted the message (because it too was down) the client can not think everything is okay and so no messages will be mysteriously missed.
More practically though, the durability property indeed assumes a single topic to which multiple remote clients are listening. If your setup is such that you already had multiple listeners on different remote servers for a topic, I guess you wouldn't be asking this question. So I assume you have your MDB(s) all deployed on a single server.
In that case, separating the JMS provider could improve your robustness, as the server running just this provider might have a lower risk to crash (smaller more dedicated system, especially without your own code = less likely to crash) and could function as a buffer for those situations where you have to restart your application server. On the other hand, with each server you add the chance that at least one of them crashes increases and the possibility that you make a configuration error somewhere increases as well. This is a tradeoff you have to make your self.