Spring JMS 错误处理的最佳实践
我正在开发一种基于消息的服务，该服务将对所有传入请求进行排队并稍后处理它们。处理错误的最佳实践是什么。例如，将信息发送到下一个系统时出现格式错误的消息或通信错误。
通过使用事务，可以处理后者，但是当消息格式错误时，重试或保留它是没有用的。是否有针对不同场景实现不同错误处理的想法，如果是，应该如何完成？
谢谢！
I'm working on a message based service that queues all incoming requests and handles them later. What is the best practice for handling errors. For example malformed messages or communication errors when sending the information to the next system.
By using transactions it is possible to cope with the latter, however when a message is malformed there is no use to retry it nor keep it. Is there any idea to implement different error handling for different scenarios and if it is, how should it be done?
Thanks!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我认为你走在正确的道路上。这里有三种一般模式：
应用正常处理。
可能处理该消息所需的某些资源不可用。在这种情况下，将事务设置为rollbackOnly，消息将被重新传递。希望您的 JMS 实现支持延迟重新传递的概念，这样您就不会在 MIA 资源再次可用之前重新处理同一消息数千次。如果没有（是的，我正在看你，WebSphere MQ），我通常做的就是将消息推送到另一个为暂时无法处理的消息保留的 JMS 队列中并提交。当 MIA 资源重新上线时，我按程序读取该队列中的所有消息，并将它们写回主[原始]队列，并在其中处理完成。
抑制异常并提交事务。您将永远不会再看到该消息。要保留无效消息的审核跟踪：
不过，要点是确保在您知道的情况下提交事务 em> 您将永远无法处理该消息。
I think you're on the right track. There's three general patterns here:
Normal processing applies.
Perhaps some resource you need to process the message is unavailable. In this case, set the transaction to rollbackOnly and the message will be redelivered. Hopefully your JMS implementation supports the notion of delayed redelivery so that you're not reprocessing the same message thousands of times until your MIA resource becomes available again. If not (yeah, I'm looking at you, WebSphere MQ), what I usually do is push the message into another JMS queue reserved for temporarily unprocessable messages and commit. When the MIA resource comes back on line, I procedurally read all the messages off that queue and write them back to the main [original] queue where they're processed to completion.
Suppress the exception and commit the transaction. You'll never see that message again. To keep an audit trail of invalid messages:
The main point, though, is to make sure you commit the transaction if you know you will never be able to process that message.