如何处理WCF的MSMQ绑定中的消息失败 [英] How do I handle message failure in MSMQ bindings for WCF
问题描述
我已经创建了WCF服务，并且正在使用netMsmqBinding绑定.
I have create a WCF service and am utilising netMsmqBinding binding.
这是一个简单的服务，它将Dto传递给我的服务方法，并且不期望响应.邮件被放置在MSMQ中，一旦被拾取，便被插入到数据库中.
This is a simple service that passes a Dto to my service method and does not expect a response. The message is placed in an MSMQ, and once picked up inserted into a database.
确保没有数据丢失的最佳方法是什么.
What is the best method to make sure no data is being lost.
我尝试了以下两种方法:
I have tried the 2 following methods:
-
引发异常
Throw an exception
这会将邮件放入死信队列中，以供人工阅读.我可以在我的服务开始时进行处理
This places the message in a dead letter queue for manual perusal. I can process this when my strvice starts
在绑定上设置receiveRetryCount ="3"
set the receiveRetryCount="3" on the binding
3次尝试后-立即发生，这似乎使消息排在队列中，但对我的服务造成了错误.重新启动我的服务会重复此过程.
After 3 tries - which happen instantanously, this seems to leave the message in queue, but fault my service. Restarting my service repeats this process.
理想情况下，我想执行以下操作:
Ideally I would like to do the follow:
尝试处理消息
- 如果失败，请等待5分钟，然后再试一次.
- 如果该过程失败3次，则将邮件移到一个死信队列中.
- 重新启动服务会将死信队列中的所有消息推回到队列中，以便对其进行处理.
我可以实现吗?如果可以，怎么办? 您能否指出我关于如何在给定场景中最佳利用WCF和MSMQ的任何优秀文章.
Can I achieve this? If so how? Can you point me to any good articles on how best to utilize WCF and MSMQ for my given sceneria.
任何帮助将不胜感激.谢谢！
Any help would be much appreciated. Thanks!
一些其他信息
我在Windows XP和Windows Server 2003上使用MSMQ 3.0. 不幸的是，我无法使用针对MSMQ 4.0和Vista/2008的内置的毒害邮件支持.
I am using MSMQ 3.0 on Windows XP and Windows Server 2003. Unfortunately I can't use the built in poison message support targeted at MSMQ 4.0 and Vista/2008.
推荐答案
SDK中有一个示例可能对您有用.基本上，它所做的是将IErrorHandler实现附加到您的服务，该实现将在WCF声明消息为中毒"(即，当所有已配置的重试用尽后)时捕获错误.该示例所做的是将消息移至另一个队列，然后重新启动与该消息关联的ServiceHost(因为在发现有毒消息时它将出现故障).
There's a sample in the SDK that might be useful in your case. Basically, what it does is attach an IErrorHandler implementation to your service that will catch the error when WCF declares the message to be "poison" (i.e. when all configured retries have been exhausted). What the sample does is move the message to another queue and then restart the ServiceHost associated with the message (since it will have faulted when the poison message was found).
这不是一个非常漂亮的示例，但它可能会很有用.但是，有两个限制:
It's not a very pretty sample, but it can be useful. There are a couple of limitations, though:
1-如果您有与服务相关联的多个端点(即通过多个队列公开)，则无法知道有害消息到达的队列.如果只有一个队列，这将不是问题.我还没有看到任何官方的解决方法，但是我已经在这里记录了一种可能的替代方法:
1- If you have multiple endpoints associated with your service (i.e. exposed through several queues), there's no way to know which queue the poison message arrived in. If you only have a single queue, this won't be a problem. I haven't seen any official workaround for this, but I've experimented with one possible alternative which I've documented here: http://winterdom.com/weblog/2008/05/27/NetMSMQAndPoisonMessages.aspx
2-将问题消息移至另一个队列后，这将由您负责，因此，一旦超时完成(或将新服务附加到该队列以进行处理)，则由您决定将其移回到处理队列中).
2- Once the problem message is moved to another queue, it becomes your responsibility, so it's up to you to move it back to the processing queue once the timeout is done (or attach a new service to that queue to handle it).
说实话，无论哪种情况，您都在这里看一些WCF本身无法涵盖的手动"工作.
To be honest, in either case, you're looking at some "manual" work here that WCF just doesn't cover on it's own.
我最近一直在另一个项目中工作，我需要明确控制重试的频率，而我目前的解决方案是创建一组重试队列，并在重试队列和主要处理之间手动移动消息基于一组计时器和一些启发式方法的队列，只使用原始的System.Messaging东西来处理MSMQ队列.这样做似乎很不错，尽管如果您按照这种方式进行操作，可能会遇到一些麻烦.
I've been recently working on a different project where I have a requirement to explicitly control how often retries happen, and my current solution was to create a set of retry queues and manually move messages between the retry queues and the main processing queue based on a set of timers and some heuristics, just using the raw System.Messaging stuff to handle the MSMQ queues. It seems to work pretty nicely, though there are a couple of gotchas if you go this way.
这篇关于如何处理WCF的MSMQ绑定中的消息失败的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
