问题标签 [netmsmqbinding]

我有一个使用 netMsmqBinding 将 queueTransferProtocol 设置为 Srmp 的 Windows 服务调用 WCF Web 服务。

所有这些都非常有效，除非托管 Web 服务的应用程序池重新启动或回收。

获取要发送的消息的唯一方法是手动浏览到 URL，或使用一些 http ping 实用程序。激活 URL 后，WCF Web 服务开始使用传入队列。

我在切换到 Srmp 之前遇到了这个问题，我通过在 Web 服务器上安装 WCF 激活功能并适当地命名队列来解决它。

由于防火墙限制，我被迫使用 Srmp，因此端口 80 或 443 是我唯一的选择。

这里有一个解决方法，我可以设置一个计划任务来按计划调用每个 Web 服务，但我更喜欢更简单更健壮的解决方案。

一个完整的解决方案会非常好，但我愿意考虑其他一些解决方法。

我正在使用 IIS/WAS 激活在 MSQM 上执行第四次或第五次 WCF 服务实现。而且我永远无法使其正常工作。这总是同样的故事：只有当 IIS 网站以其他方式交互时（例如在 /somewhere/myService.svc 处为服务元数据页面提供服务），我的服务才会被激活。突然，如果唯一发生的事情是将消息发送到队列中，我的服务将停止处理消息，并在我访问 .svc 页面后立即重新启动......

这对我来说是一个很常见的模式，我也找到了一个常见的解决方案：安排一个作业（每隔几分钟）运行一个访问该页面的 powershell 脚本。很简单，但不是很优雅。而且，更进一步，理论上是不必要的。

这发生在不同的 IIS 版本（7.0 和 7.5）、各种 Win 2008 服务包和版本以及 AD 域或工作组中的服务器上。我想我已经阅读了网络上关于此的所有内容，尤其是 MSDN 和 microsofties 博客，因此绑定配置、MSMQ 权限以及您可以在这里和那里发现的所有其他小细节都已设置好。

那么问题来了：有没有人通过 MSMQ 成功使用 WAS？

我们使用 MSMQ 对发送到在 Windows Server 2012 上运行的内部服务总线的消息进行事务处理，并且在消息处理失败时遇到了问题。

服务的设置

服务

捆绑

如您所见，我们每 1 小时运行一个周期，每条消息重试次数限制为 100 次。由于消息的 TTL 是 24 小时（默认），因此默认情况下永远不会实现这一点。

我们在 MSMQ 中的事务可能会由于第三方执行的过程而失败。消息被丢弃到重试子队列中。更多的进来，同样的事情发生。现在说，例如我们有 20 次失败。

因为它目前只有第一条消息（有时也是第二条？）将被重试，这很可能有相同的失败过程，所以我们再次不提交事务。

我希望所有达到重试周期时间跨度的消息都被移动到主队列以再次尝试，但这不会发生。顶部消息将继续阻塞，直到达到其 TTL 或最终成功。

是一种将队列行为设置为不阻塞和处理已达到重试时间跨度的所有消息的方法。

我们处于这样一种情况，如果说在 10 分钟内收到 20 条消息，如果它们都失败了，则只有第一条消息每小时重试一次，而其他 19 条则坐在那里，直到第一条消息达到 TTL，然后它们会被尝试和因为他们已经达到了 TTL，所以他们也会从重试队列中删除。

我知道消息传递是在 FIFO 的基础上工作的，并且在 vista 上的 MSMQ 之前，消息失败会阻塞其他消息，因此会阻塞重试消息队列。但这不是把问题转移到了重试子队列上吗？

我正在将 MSMQ 4 与 WCF 一起使用。我们有一个 Microsoft Dynamics 插件将消息放入队列。服务获取消息并向另一个 Web 服务器发出 HTTP 请求。Web 服务器通过将另一条消息放在不同的队列中来响应。第二个服务接收消息并将响应发送回 Dynamics...

我们将重试队列设置为重试 3 次，然后等待 5 分钟再重试。Dynamics 系统有时需要很长时间（由于其他插件），我们可以在数据库事务提交之前往返。用户在 5 分钟内没有看到更新。

我很好奇是否有办法配置重试机制以增量重试。因此，第一次失败时，它只等待几秒钟。如果它第二次失败，它会等待两次。重试之间的时间不断增长。

仅减少重试之间的时间的问题在于，错误消息很容易填满日志文件。

我们有一个 WCF 服务，用于侦听队列 (MSMQ) 上的消息。它向我们的 Web 服务器 (REST API) 发送一个请求，该服务器返回一个 HTTP 状态代码。

如果状态码在 400 范围内，我们将丢弃该消息。这个想法是 400 范围错误永远不会成功（未经授权、错误请求、未找到等），因此我们不想继续重试。

对于所有其他错误（例如，500 - 内部服务器错误），我们将 WCF 配置为将消息放在“重试”队列中。重试队列上的消息会在一定时间后重试。这个想法是服务器暂时关闭，所以等待并重试。

WCF 的设置方式，如果我们FaultException在服务契约中抛出一个，它会自动将消息放到重试队列中。

当消息导致 400 范围错误时，我们只是在吞下错误（我们只是记录它）。这可以防止重试机制触发；但是，最好将消息移动到死信队列。这样，我们可以通过向用户和/或系统管理员发送电子邮件来对错误做出反应。

有没有办法立即将这些坏消息移动到死信队列？

我正在将 WCF 与 MSMQ 端点一起使用，并且看到了这个问题中描述的行为- 基本上，虽然服务被限制为一次处理一条消息，但从队列中获取了 2 条消息，其中一条似乎保存在内存中，而另一条则正在处理。

这给监控正在发生的事情带来了问题。我有一个监控页面，它显示哪些作业在队列中，哪些正在处理中，但由于这种行为，有一段时间作业在从队列中取出但尚未开始处理时实际上消失了。我MessageQueue.GetAllMessages()用来获取当前队列中的消息列表。

我对 MSMQ 不太熟悉，但我假设当一条消息出列时，它会被标记为不可见，这样其他进程就不会将其删除。有没有办法查询这些消息，以便我可以看到它们是什么？

我正在尝试第一次运行 MSMQ 服务。

我从 MSDN 复制了一个示例，我正在尝试让它工作。

一切运行正常，没有错误。然而，当我去检查我的 MSMQ 时，没有可用/添加的消息。

我使用了跟踪工具 SvcTraceViewe.exe 并且没有报告错误。

这是我在类 DLL 中定义的服务：

这是我调用上述 DLL 的服务器主机：

这是我在主机应用程序中的 app.config 设置：

这是调用服务的客户端应用程序：

这是我的客户端 app.config：

我已检查我的消息队列是否已创建。

1）。消息如何添加到队列中？我的服务中的空方法有什么意义？2）。为什么我的消息没有被添加？

谢谢

注意

将代码更改为：

我们正在使用 .NET 4.5 构建 Workflow Foundation 服务，并尝试使用 MSMQ 传递 Workflow Service 应处理的消息。

我们启用了允许缓冲接收，以便让消息等待 Workflow 能够处理它们。

但是，我们的消息文件夹中出现了一些奇怪的锁（参见图片）。

没有任何文件可以解释这一点。这是什么？和WF、WCF、MSMQ有关系吗？在哪里寻找解决方案？

我已经为此工作了一周并广泛使用了 StackOverflow，但我无法弄清楚这一点。

我正在 Autodesk 产品中用 C# 编写插件，并且我已（与 Marshal）连接到不同的 3D 应用程序。过去我已经为其他几十个插件做到了这一点，没有问题。

这个项目是独一无二的。在不同的 3D 应用程序中，我正在一个大型模型上运行一个长时间运行的任务（文件导出）。有时需要1-60分钟。

我收到毒消息：“此操作无法完成，因为'应用程序'没有响应。选择“切换到”并...” 从技术上讲，我可以让客户端只需单击“重试”，直到找到应用程序，但是这是不可取的。

我原本以为我只会放一个 DoEvents 类型的东西，它会等待导出完成，但是在导出子运行时会出现毒消息（这是我第一次出现毒消息，所以我正在学习）。然后我研究了在后台线程上运行这个导出操作，测试 ThreadPool 和 Thread 操作。但是，我可以“启动”该服务，但它永远不会从不同的 3D 应用程序中导出模型。它只是永远运行。 （我从原始帖子中删除了错误消息，因为我不是在寻找解决该子问题的方法，而是在寻找我将在下面描述的内容）

最后，我尝试修改 NetMsmqBinding（我对此也一无所知，但正在努力学习它），希望它将允许的重试次数设置为更大的数字。

但是，无论我将 NetMsmqBinding 值更改为什么，我总是同时收到“重试”消息。我一定写得不对。在其他示例中，我注意到一个包含这些值的 xml 文件，但我不知道该 xml 是什么。我也不想知道，因为我宁愿让这个在插件中运行，而不是有另一个 xml 文件来处理。

我在假设中找到了很多关于如何处理这个问题的例子（很多 console.write BS），但实际上没有一个具体的例子，即长时间运行的 COM 进程正在中断主要的 C# 实用程序。

我真的很想弄清楚如何将重试频率和周期重置为持续更长时间，这样就不会出现毒消息。我怎样才能做到这一点？

这是更多代码，以提供一些上下文：

我收到一个“忙碌”消息框，其中显示以下内容：“此操作无法完成，因为“CATIA - 产品 - [testfile.CATPart]”程序没有响应。” 从“切换到...”“重试”或“取消”中选择。

问题：我需要找到一种编程方式来确保消息框永远不会出现。

背景：我正在使用 C#.net 开发一个 AutoDesk 插件，该插件临时访问非 Autodesk 3D 应用程序。它正在远程访问非 Autodesk 3D 应用程序（使用 marshal）并进行长文件导出。文件导出时，时间过长，并出现消息。如果我等待，我可以在 Windows 资源管理器中看到文件完成后单击重试，并且一切正常。但是，我不能指望客户一直喜欢单击“重试”。我需要它来忘记消息并继续等待，如果可能的话无限期地等待。一些文件导出可能需要一个多小时，而这些文件甚至还没有那么大。

我已经尝试了几件事，但是由于我无法访问 exe（这是一个 dll），因此我似乎对修改 netmsmqbinding 设置的访问权限有所限制。我尝试了几种不同类型的队列和服务，但它们都可以正常启动和停止，但从不执行文件导出过程。理想情况下，我只想从我的 dll 中关闭任何潜在的消息框，但如果这不可能，我可以将 netmsmqbinding 设置重置为很长的时间吗？这对我不起作用：