blocks|key|364879|text|我认为使用MSMQ+(仅在Vista上可用)，您可以这样做：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|364880|<bindings>
++++<netMsmqBinding>
++++++++<binding+name="PosionMessageHandling"
+++++++++++++receiveRetryCount="3"
+++++++++++++retryCycleDelay="00:05:00"
+++++++++++++maxRetryCycles="3"
+++++++++++++receiveErrorHandling="Move"+/>
++++</netMsmqBinding>
</bindings>|code-block|syntax|javascript|364881|在第一次调用失败后，WCF将立即重试ReceiveRetryCount次数。批处理失败后，消息将移动到重试队列。在RetryCycleDelay分钟的延迟之后，消息从重试队列移动到端点队列，并且批处理被重试。这将重复MaxRetryCycle时间。如果所有失败的消息都根据receiveErrorHandling处理，则可以移动(毒害队列)、拒绝、丢弃或出错|364882|顺便说一下，Juval+Lowy的Progammig+WCF书的第9章中有一篇关于WCF和MSMQ的好文章|364883|entityMap^0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|M|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|N|8|@]|9|@]|A|$E|F]]|$1|G|3|H|5|6|7|O|8|@]|9|@]|A|$]]|$1|I|3|J|5|6|7|P|8|@]|9|@]|A|$]]|$1|K|3|-4|5|6|7|Q|8|@]|9|@]|A|$]]]|L|$]]

I think with MSMQ (avaiable only on Vista) you might be able to to do like this:

<pre><code>&lt;bindings&gt;
 &lt;netMsmqBinding&gt;
 &lt;binding name="PosionMessageHandling"
 receiveRetryCount="3"
 retryCycleDelay="00:05:00"
 maxRetryCycles="3"
 receiveErrorHandling="Move" /&gt;
 &lt;/netMsmqBinding&gt;
&lt;/bindings&gt;
</code></pre>

WCF will immediately retry for ReceiveRetryCount times after the first call failure. After the batch has failed the message is moved
to the retry queue. After a delay of RetryCycleDelay minute, the message moved from the retry queue to the endpoint queue and the batch is retried. This will be repeated 
MaxRetryCycle time. If all that fails the message is handled according to receiveErrorHandling which can be move 
(to poison queue), reject, drop or fault

By the way a good text about WCF and MSMQ is the chapther 9 of Progammig WCF book from Juval Lowy

blocks|key|3370707|text|不幸的是，我被困在Windows+XP和Windows+Server2003上，所以这对我来说不是一个选择。-(我将在我的问题中重新澄清，因为我在帖子后找到了这个解决方案，并意识到我不能使用它)|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3370708|我发现一种解决方案是设置一个自定义处理程序，它会将我的消息移动到另一个队列或毒化队列，然后重新启动我的服务。在我看来这太疯狂了。假设我的Sql+Server宕机了，重新启动服务的频率是多少。|3370709|所以我最终要做的就是允许Line出错并将消息留在队列中。我还向我的系统日志记录服务记录了一条致命的消息，表明发生了这种情况。一旦我们的问题得到解决，我重新启动服务，所有的消息都会再次开始处理。|3370710|我意识到重新处理此消息或任何其他消息都将失败，所以为什么需要将此消息和其他消息移动到另一个队列。我可能会停止我的服务，并在一切正常运行时重新启动它。|3370711|aogan，你有MSMQ+4.0的完美答案，但不幸的是不适合我|3370712|entityMap^0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|L|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|M|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|N|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|O|8|@]|9|@]|A|$]]|$1|H|3|I|5|6|7|P|8|@]|9|@]|A|$]]|$1|J|3|-4|5|6|7|Q|8|@]|9|@]|A|$]]]|K|$]]

Unfortunately I'm stuck on Windows XP and Windows Server 2003 so that isn't an option for me. - (I will re-clarify that in my question as I found this solution after posting and realised i couldn't use it)

I found that one solution was to setup a custom handler which would move my message onto another queue or poison queue and restart my service.
This seemed crazy to me. Imagine my Sql Server was down how often the service would be restarted.

SO what I've ended up doing is allowing the Line to fault and leave messages on the queue.
I also log a fatal message to my system logging service that this has happened.
Once our issue is resolved, I restart the service and all the messages start getting processed again.

I realised re-processing this message or any other will all fail, so why the need to move this message and the others to another queue. I may as well stop my service, and start it again when all is operating as expected.

aogan, you had the perfect answer for MSMQ 4.0, but unfortunately not for me

blocks|key|364507|text|如果您正在使用SQL-Server，那么您应该使用分布式事务，因为MSMQ和SQL-Server都支持它。实际情况是，您将数据库写操作包装在一个TransactionScope块中，并仅在成功时才调用scope.Complete()。如果失败，那么当您的WCF方法返回时，消息将被放回队列中重试。下面是我使用的代码的精简版本：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|364508|++++[OperationBehavior(TransactionScopeRequired=true,+TransactionAutoComplete=true)]
++++public+void+InsertRecord(RecordType+record)
++++{
++++++++try
++++++++{
++++++++++++using+(TransactionScope+scope+=+new+TransactionScope(TransactionScopeOption.Required))
++++++++++++{
++++++++++++++++SqlConnection+InsertConnection+=+new+SqlConnection(ConnectionString);
++++++++++++++++InsertConnection.Open();

++++++++++++++++//+Insert+statements+go+here

++++++++++++++++InsertConnection.Close();

++++++++++++++++//+Vote+to+commit+the+transaction+if+there+were+no+failures
++++++++++++++++scope.Complete();
++++++++++++}
++++++++}
++++++++catch+(Exception+ex)
++++++++{
++++++++++++logger.WarnException(string.Format("Distributed+transaction+failure+for+{0}",+
++++++++++++++++Transaction.Current.TransactionInformation.DistributedIdentifier.ToString()),
++++++++++++++++ex);
++++++++}
+++++}|code-block|syntax|javascript|364509|我通过将大量但已知数量的记录排队来测试这一点，让WCF启动许多线程以同时处理其中的许多线程(达到16个线程--一次从队列中删除16条消息)，然后在操作过程中终止进程。当程序重新启动时，将从队列中读回消息并再次处理，就好像什么都没有发生一样，并且在测试结束时，数据库是一致的，没有丢失的记录。|364510|分布式事务管理器在环境中存在，当您创建TransactionScope的新实例时，它会自动搜索方法调用范围内的当前事务--在将消息弹出队列并调用您的方法时，WCF应该已经创建了该事务。|364511|entityMap^0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|M|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|N|8|@]|9|@]|A|$E|F]]|$1|G|3|H|5|6|7|O|8|@]|9|@]|A|$]]|$1|I|3|J|5|6|7|P|8|@]|9|@]|A|$]]|$1|K|3|-4|5|6|7|Q|8|@]|9|@]|A|$]]]|L|$]]

If you're using SQL-Server then you should use a distributed transaction, since both MSMQ and SQL-Server support it. What happens is you wrap your database write in a TransactionScope block and call scope.Complete() only if it succeeds. If it fails, then when your WCF method returns the message will be placed back into the queue to be tried again. Here's a trimmed version of code I use:

<pre><code> [OperationBehavior(TransactionScopeRequired=true, TransactionAutoComplete=true)]
 public void InsertRecord(RecordType record)
 {
 try
 {
 using (TransactionScope scope = new TransactionScope(TransactionScopeOption.Required))
 {
 SqlConnection InsertConnection = new SqlConnection(ConnectionString);
 InsertConnection.Open();

 // Insert statements go here

 InsertConnection.Close();

 // Vote to commit the transaction if there were no failures
 scope.Complete();
 }
 }
 catch (Exception ex)
 {
 logger.WarnException(string.Format("Distributed transaction failure for {0}", 
 Transaction.Current.TransactionInformation.DistributedIdentifier.ToString()),
 ex);
 }
 }
</code></pre>

I test this by queueing up a large but known number of records, let WCF start lots of threads to handle many of them simultaneously (reaches 16 threads--16 messages off the queue at once), then kill the process in the middle of operations. When the program is restarted the messages are read back from the queue and processed again as if nothing happened, and at the conclusion of the test the database is consistent and has no missing records.

The Distributed Transaction Manager has an ambient presence, and when you create a new instance of TransactionScope it automatically searches for the current transaction within the scope of the method invokation--which should have been created already by WCF when it popped the message off the queue and invoked your method.

blocks|key|3158029|text|SDK中有一个可能对您有用的示例。基本上，它所做的就是将一个IErrorHandler实现附加到您的服务，该实现将在WCF声明消息为“有毒”时捕获错误(即，当所有已配置的重试都已耗尽时)。该示例所做的是将消息移动到另一个队列，然后重新启动与该消息相关联的ServiceHost+(因为当发现有毒消息时，它将出现故障)。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3158030|这不是一个非常漂亮的示例，但它可以是有用的。不过，这有几个限制：|3158031|1-如果您有多个端点与您的服务相关联(即通过多个队列公开)，则无法知道有毒消息到达哪个队列。如果你只有一个队列，这不是问题。我还没有看到任何正式的解决方法，但我已经尝试了一种可能的替代方法，我在这里记录了这一点：http://winterdom.com/weblog/2008/05/27/NetMSMQAndPoisonMessages.aspx|offset|length|3158032|2-一旦问题消息被移动到另一个队列，它就变成了您的责任，因此，在超时结束后，由您决定是否将其移回处理队列(或将新服务附加到该队列以处理它)。|3158033|老实说，不管是哪种情况，你在这里看到的都是一些“手工”工作，而WCF本身并不能涵盖这些工作。|3158034|我最近一直在做一个不同的项目，其中我需要显式地控制重试发生的频率，我当前的解决方案是创建一组重试队列，并基于一组计时器和一些启发式方法在重试队列和主处理队列之间手动移动消息，只需使用原始的System.Messaging内容来处理MSMQ队列。它似乎工作得很好，但如果你这样做，会有几个陷阱。|3158035|entityMap|0|LINK|mutability|MUTABLE|url|http://winterdom.com/weblog/2008/05/27/NetMSMQAndPoisonMessages.aspx^0|0|0|2Y|1W|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|V|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|W|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|X|8|@]|9|@$F|Y|G|Z|1|10]]|A|$]]|$1|H|3|I|5|6|7|11|8|@]|9|@]|A|$]]|$1|J|3|K|5|6|7|12|8|@]|9|@]|A|$]]|$1|L|3|M|5|6|7|13|8|@]|9|@]|A|$]]|$1|N|3|-4|5|6|7|14|8|@]|9|@]|A|$]]]|O|$P|$5|Q|R|S|A|$T|U]]]]

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- 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: <a href="http://winterdom.com/weblog/2008/05/27/NetMSMQAndPoisonMessages.aspx" rel="noreferrer">http://winterdom.com/weblog/2008/05/27/NetMSMQAndPoisonMessages.aspx</a>

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).

To be honest, in either case, you're looking at some "manual" work here that WCF just doesn't cover on it's own. 

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.

I have create a WCF service and am utilising netMsmqBinding binding.
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:
<ol>
<li>Throw an exception
This places the message in a dead letter queue for manual perusal. I can process this when my strvice starts
</li>
<li>set the receiveRetryCount=&quot;3&quot; on the binding
After 3 tries - which happen instantanously, this seems to leave the message in queue, but fault my service. Restarting my service repeats this process.
</li>
</ol>
Ideally I would like to do the follow:
Try process the message
<ul>
<li>If this fails, wait 5 minutes for that message and try again.</li>
<li>If that process fails 3 times, move the message to a dead letter queue.</li>
<li>Restarting the service will push all messages from the dead letter queue back into the queue so that it can be processed.</li>
</ul>
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!
Some additional information
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.

How do I handle message failure in MSMQ bindings for WCF

Windows Server

数据库

Windows

我已经创建了一个WCF服务，并且正在使用netMsmqBinding绑定。这是一个简单的服务，它将Dto传递给我的服务方法，并且不期望得到响应。消息被放在MSMQ中，一旦被拾取，就被插入到数据库中。确保数据不会丢失的最佳方法是什么？我已经尝试了以下两种方法：引发异常这会将消息放在死信队列中，以供手动细读。我可以在我的策...

问如何处理WCF的MSMQ绑定中的消息故障
EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问如何处理WCF的MSMQ绑定中的消息故障EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问如何处理WCF的MSMQ绑定中的消息故障
EN