问题标签 [msmq-wcf]

我有一个场景，大约需要 10 条不同的消息入队，然后出队/处理。一个订阅者需要全部 10 条消息，但另一个订阅者只需要 10 条消息中的 8 条。我试图了解设置这种架构的最佳方法是什么。您是否为每种消息类型创建一个队列，以便订阅者可以订阅相关队列，或者您是否将它们全部转储到同一个队列并忽略与该订阅者无关的消息？我想确保解决方案灵活/可扩展等。

过程：

1. 10 条不同的 xml 消息将排队到 IBM WebSphere MQ 服务器。
2. 我们将使用 .Net（很可能是 WCF，因为 WebSphere MQ 7.1 添加了 WCF 支持）
3. 我们将出列消息并将它们加载到另一个后端数据库（很可能是 SQL Server）。
4. 解决方案需要很好地扩展，因为我们将处理大量消息并且这可能会增长（可能 40-50,000 / hr）。至少对我们来说很大。

一如既往地非常感谢这些信息。

--S

我们在整个系统中有许多 MSMQ 队列，包括私有队列和公共队列。有时，从队列中读取的 Windows 服务会崩溃，因此消息会在该队列中堆积。一旦队列达到一定大小（可能是 60K 消息），该服务器上的所有队列都将停止工作，并抛出有关资源不足的错误。

我的问题是，队列在幕后是如何真正工作的，它们是将消息存储在 RAM 中还是硬盘上？当服务器内存不足时，它是否会耗尽资源并崩溃？如果它正在使用硬盘驱动器上的一些分配空间，有没有办法增加允许的大小？如果它使用 RAM，我可以简单地将 RAM 添加到服务器，然后这会增加允许的大小吗？

我需要确保当服务出现故障时，我们可以在修复服务时处理在该队列中存储 100K 或 200K 消息，因为这些消息对我们的业务至关重要。

我在尝试让工作流 (WF4) 调用长时间运行的 WCF 服务并在 WCF 服务完成时恢复处理时遇到问题。下图粗略地概述了我想要实现的目标。如果您能指出任何演示这种情况（或非常相似的情况）的示例，我们将不胜感激。有关信息，我已经看到了很多 WF 到 WF 的示例，但这些示例并没有真正帮助。

这是一个简单的问题，但我找不到答案。

假设我的消息被放置到重试队列（谁创建重试队列？它是 WCF 还是 MSMQ 服务？）

5 分钟后（这是我的重试延迟），该消息返回到应用程序队列。

问题：谁在超时后将消息从重试队列移动到应用程序队列？

额外的问题：如何跟踪延迟？消息是否获得“移动”时间戳和“重试”时间戳？

据我了解，为 net.msmq 配置的 WCF 服务在 IIS/WAS 中托管时不会作为 HttpApplication 运行，这意味着您不会在全局中获得事件（Application_Start 是重要的事件）。我在这方面是正确的吗？

使用 Windows Server AppFabric 自动启动服务是否会通过 HTTP 命中服务，导致 Application_Start 事件触发？如果是这样，这可靠吗？

我想我真正的问题是，非 HTTP WCF 服务的初始化代码的“正确”位置在哪里？

特别是（因为不同的东西的正确位置可能不同）：

• 国际奥委会注册
• log4net 初始化
• 验证本地是否存在 MSMQ 队列（正如 Juval Lowy 在他的 WCF 书中所建议的那样）

后续问题：自定义 IServiceBehavior 中的事件是在每次请求时触发还是仅在启动时触发一次？ServiceHost.OnOpening() 怎么样 - 每个请求或仅在启动时一次？（我的测试表明它只有一次，但有人知道 WCF“生命周期”记录在哪里，因为我似乎无法在任何地方找到它。）

我有一个 WCF 激活的工作流服务 (XAMLX) 设置（使用 WorkflowServiceHost 托管）。

此 WCF WebService 具有“NetMsMqBinding”绑定和基于 net.msmq 的端点，客户端使用该端点来安排操作。

在客户端，我使用 Visual Studio 生成代理存根以与此 WCF 服务进行通信。一切正常，我可以看到消息出现在服务器上的（日志式）MQ 中，WCF 从队列中提取消息以根据消息激活配置的工作流。

我需要控制发送到 MQ 的消息的优先级，以便某些 WCF 客户端可以优先处理其工作流。

似乎 NetMsMqBinding 并不真正支持 MQ 消息优先级。它是否正确？如果是这样，我该如何实现/模拟呢？我可以使用 MQ 触发器根据某些标志更改消息的优先级吗？

不是 MSMQ 或 WCF 方面的专家，我已经阅读了一些关于它的内容，它听起来和看起来都很棒。我正在尝试开发一些东西，但首先是一些理论，它需要坚固耐用。

我猜 MSMQ 将托管在单独的服务器上。

将有 2 个 WCF 服务。一个用于传入消息，另一个用于传出消息（接收消息，进行一些内部处理/验证，然后将其放在传出消息队列中，或者可能发送电子邮件/短信/其他）

我理解通过正确的配置，我们可以让系统成为事务性的（永远不会丢失任何消息）并且可以只发送一次，因此没有重复消息的机会。

应用程序/服务将是多线程的以处理消息，其中将有成百上千的消息。

但是在处理消息或通过服务生命周期期间，如果服务器崩溃怎么办？如果服务器重启怎么办？如果服务出于某种原因抛出异常怎么办？怎么可能不丢失该消息，但如何将其放回队列等待再次处理？另外，如何确保该服务是健壮的，以使其再次产生自己？

我很感激这里的任何建议和细节。有很多东西可以吸收，WCF/MSMQ 提供了很多选项。

我正在尝试开发一个 WCF 服务来处理数百次下载和转换。我已经使用从 ASP.NET Web 应用程序接收消息的事务队列初始化 MSMQ。

在互联网上长期研究后，我的问题是如何管理管理 MSMQ 消息的 WCF 服务方法中的长进程。

问题是在小尺寸下载时，该过程很快完成并且范围返回到MSMQ服务，但是如果下载大小很大并且需要3/4分钟下载，则范围返回仍然完成，但是MSMQ 服务将 MSG 重新发送到 WCF 服务，我有重复下载。

我想这是超时的问题，但我已经尝试更好地配置我的 Host app.config 没有成功。

这是进入 WCF 服务的方法：

更新

经过长时间的试验和研究，我开始认为将长时间的过程变成由 MSMQ 队列触发的方法是不可能的。

我使用另一个管理数据的线程来解决它，但现在的问题是我失去了 TransactionScope 优势，因为一旦工作传递给新线程，MSMQ 就会删除 msg，因为相信已经完成。

我们有许多发送数据包的通信服务器。我们希望将来自这些服务器程序的这些数据包存储在 MSMQ 中，直到更新程序处理它们。数据丢失一直是一个问题，我们希望不丢失来自这些服务器程序的任何数据包，并希望有一个高效和高性能的解决方案。

最好的设计方法是什么？

I have this scenario, guys-

A typical large-scale CMS application in which the following business transactions appear:

• Users publish content immediately.
• Users schedule content to be published.
• Automatic process runs ,say, in 10 minutes interval, collects scheduled and ready (simply a status of the BO)content and sends it to publishing.

This is oversimplified description of the actual system. By saying publishing I mean a complex process consisting of 4 main sub-systems: building invocation arguments, generating html content by running another web app(asp.net), committing the transactional parties, and signaling the users about the publishing results. So the system looses ability to run the whole process in a single Mega-transaction, i.e. it's possible but not practical from the scalability/performance points of view.

There are several options for the sub-systems to communicate each other, like making use of MSMQ, SQL Service Broker, NServiceBus, and a chain of plain WCF one-way invocations (which is currently implemented). So, guys, I'm looking for some possibly more reliable and scalable solution for this processing because looks like the system will be getting more busy with growing number of users and , therefore, more content to be generated. Especially, once, mobile versions' support is requested by the clients.

One of my considerations is to queue all the users immediate requests using MSMQ where a dedicated WCF service will dispatch them next to the content generation module (web app). And so will do the windows scheduled task. I can't see how these messaging platforms could be useful but not residing them before the html generation. This really confuses me.

Can't figure out what technology will fit best for this on my own.Any help, considerations, sharing your experience will help me, guys.