Weblogic/消息驱动Bean处理问题
技术：
Jave EE、Weblogic 10.3、JMS
场景：
一个 EJB 模块，例如 Module_1，具有 3 个不同的消息驱动 Bean (MDB) 类，用于监视 3 个不同的 Java 消息队列 (JMS) ）。消息不断被添加到这些 bean 中。
问题：
每天一次，在某个时间，我需要重新启动整个Weblogic服务器而不丢失任何消息。此外，该服务器上还部署了另一个模块，例如 Module_2。我需要确保 Module_2 在 Module_1 之前启动。
如果任何 MDB 在预定义的关闭时间正在处理任何消息，那么我想我将不得不等待它完成。但不确定。
有人可以建议任何标准方法/配置来实现这一目标吗？
另外，如果Weblogic服务器不经意地直接重新启动怎么办？这将如何影响仍在队列中的消息和正在处理的消息？
谢谢。
Technologies:
Jave EE, Weblogic 10.3, JMS
Scenario:
An EJB module, say Module_1, with 3 distinct Message Driven Bean (MDB) classes monitoring 3 different Java Mssage Queues (JMS). Messages are constantly being added to these beans.
Problem:
Once every day, at a certain time, I need to restart the entire Weblogic Server without losing any message. Also, there is another module deployed on this server, say Module_2. And I need to make sure that Module_2 starts before Module_1.
If any message is being processed by any of the MDB at the predefined shutdown time, then I guess I will have to wait for it to finish. Not sure of it though.
Can someone suggest any standard approach/configuration to acheive that?
Also, what if the Weblogic Server is directly restarted without any sort of care? How will that affect the messages still in queue and those which were in the middle of processing?
Thanks.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
模块启动的顺序是一个配置参数：查看config.xml中的
10200 至于关闭，您需要执行“正常关闭”(http://docs.oracle.com/cd/E13222_01/wls/docs81/adminguide/overview_lifecycle.html#1045901)。这应该使队列停止接受新消息，确保所有消息都被持久化，然后等待任何正在处理的消息。只有这样它才会停止。
如果您在发生硬故障后重新启动，则将重新处理正在进行的消息，因为它未正确完成。通常，这是预期的行为。
The order in which modules are started is a config parameter: check out
<deployment-order>10200</deployment-order>in config.xml. Lower numbered module gets deployed before higher-numbered module.As to the shutdown, you will want to do a "Graceful Shutdown" (http://docs.oracle.com/cd/E13222_01/wls/docs81/adminguide/overview_lifecycle.html#1045901). This should make the queue stop accepting new messages, make sure all messages are persisted, then wait for any in-flight messages to become processed. Only then will it stop.
If you restart after a hard failure, the in-flight message will be re-processed because it was not completed properly. Usually, this is the expected behaviour.