JMS p2p 故障转移模式以保证交付
我是一名 Web 开发人员，最终从事了一些 j2ee 开发（新手）。我真诚地需要证实这个理论。
当用户点击保存按钮时，我有权将消息从我们的系统（生产者）传递到 SOA Enterprice 服务总线（消费者）。信息不得遗漏或未送达，且必须保留送货单。
环境：
- Jboss eap 5.1作为生产者。
- JNDI 服务器是 ESB（也许是标准的）。
- Jboss ESB 作为消费者。
由于异步特性，我选择的武器是 JMS、p2p。
当生产者即将发送消息时，可能会出现一些问题：
- ESB 关闭导致 JNDI 异常
- 队列管理器由于某种原因未唤醒或配置错误。这应该会导致一些 JMS 异常。
- 网络中断，导致 JMS 错误。
所以我正在寻找一些故障转移模式。我的建议如下：
- 添加一个最初添加消息的内部 JMS 队列。
- 添加一个侦听内部队列并尝试将其发送到目标队列 (ESB) 的 MDB。
- 如果以任何方式失败，请记录 fatal 并发送电子邮件给出色的支持人员。
这应该生成一个可靠的模式，其中消息保留在内部队列上，直到由 MDB 处理。
请指教。
最好的问候
ds
Im a web developer ended up in some j2ee development (newbie). I sincerely need this theory confirmed.
I been given the privilege to deliver a message from our system (producer) to the SOA Enterprice service bus (consumer) when the user hits the save button. The information can not be missed or not delivered and the delivery order must be kept.
Environment:
- Jboss eap 5.1 as the producer.
- JNDI server is the ESB (maybe standard).
- Jboss ESB as the consumer.
My weapon of choice is JMS, p2p, due to the asynchronous nature.
When the producer is abut to send the message some problems can occur:
- ESB is down causing JNDI exception
- Queue manager is for some reason not awake or wrongly configured. This should cause some JMS exception.
- Network hickup, causing a JMS error.
So Im looking for some failover pattern. Here is my suggestion:
- Add a internal JMS queue to which the message is initially added.
- Add a MDB that listen to the internal queue and tries to send it to the target queue (ESB).
- If failing in any way log fatal and send email to cool support people.
This should generate a reliable pattern where a message remains on the internal que until processed by the MDB.
Please advice.
Best Regards
ds
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
嗯，“临时”队列并不是一个完全坏的主意，但是在从一个队列移动数据到将其放入另一个队列的过程中，您将面临潜在的风险窗口。尽管这个窗口几乎没有，但如果你当时就遇到了一些失败，会发生什么？ -你必须将消息放回到队列中（并且在那里你会遇到以正确的顺序获取它的问题 - 讨厌的东西！）或者以某种方式保留它，直到你将它放入另一个队列（如果您遇到某种失败情况，这反过来可能会很麻烦。
更稳定的解决方案是将数据放入带有队列顺序列的数据库中。然后，您可以按正确的顺序选择数据，将其发送到新队列，最后将其标记为“完成”或其他内容，甚至（更好？）删除数据库中的数据。
Well a 'temporary' queue is not a totally bad idea, but during the time from moving data from one queue to putting it on another you'll have a potential window of risk. Even though that window is close to nothing, what would happen if you got some failure right there and then? -You'd have to put the message back on the queue (and there you'd get into the problem with getting it in the correct order - nasty stuff!) or hold on to it in some way until you put it the other queue (which in turn can be cumbersome if you'd e g get into some failure-situaton.
A more stable solution would be to put data in a db with a queue-order column. You can then select your data in the correct order, send it to the new queue, and finally flag it as 'done' or something or even (better?) remove the data in the db.