我正在解决WCF通过事务性MSMQ(带有netMsmqBinding)发送的消息似乎消失的问题。使用WCF的代码是在第三方程序集中,我无法更改。我没有解决问题的线索,但计划启用各种跟踪功能以确定问题所在的位置。
我启用了MSMQ End-to-End Tracing。它为每个发送的消息记录两个事件。
我已启用详细WCF Tracing。
我还有应用程序级日志记录,记录应用程序代码定义的消息ID(我们称之为“应用程序消息ID”)。
我在已发送的MSMQ消息上启用了正面和负面日记功能。
我已在接收队列上启用了日记功能。
当消息丢失时,我知道丢失消息的应用程序ID(它由发送方记录)。我现在想看一下End-to-End跟踪 消息是否写入传出队列。
如何将端到端跟踪中的事件与应用程序级别日志和WCF跟踪相关联?
在System.Messaging中使用托管MSMQ API发送MSMQ消息时,消息的MSMQ ID在发送消息后可用。但是,当WCF执行发送操作时,我还没有找到记录此方法的方法。 WCF跟踪记录了一个MSMQMessageId guid,但令人惊讶的是,这个值并不是我猜想的实际MSMQ id。 是否可以访问实际的MSMQ邮件ID并进行记录?
在应用程序日志中记录本机线程ID以及应用程序级别ID和时间戳。 MSMQ将本机线程ID记录到端到端跟踪中,因此实际上这可能足以进行关联。如果我找不到更优雅的解决方案,这是我的计划B.
答案 0 :(得分:1)
你听起来像是在正确的轨道上。但是你可以用这个来提高一点:
使用SvcConfigEditor.exe
答案 1 :(得分:0)
您可以将Windows MSMQ配置为感知消息主题,如果主题包含关键词,则触发应用程序。此应用程序可以记录传入的消息在发送方,您可以将实际的消息ID写入消息的主题,并将您的关键字添加到主题。在接收方激发的应用程序可以访问主题中添加的关键字附近的实际消息ID。
答案 2 :(得分:0)
看起来你的消息被WCF丢弃了,因为它在某种程度上是畸形的(即合同不匹配,超出了WCF消息大小限制之一)。
要捕获此错误,您可以编写一个ErrorHanlder来审核这些错误。 这里有一个link样本。
另一个选择,如果您使用的是Win 2008 R2及更高版本,则使用内置的有害消息处理。这里是文档的link。
问题,使用应用程序跟踪标识符来端到端跟踪: 我会在消息头(look here for an example)中传递应用程序跟踪ID。
要审核服务端的邮件标题,我会使用WCF的IOperationInvoker
来拦截每个调用,并审核messaged标头中的id。
这可以在进程的配置文件中配置,而无需更改第三方代码。here`s 如何实现调用程序以及如何在config中设置它的示例。