问题标签 [msmq-transaction]

有人能告诉我 MSMQ（使用事务）是否支持竞争消费者吗？基本上，我有多个线程将消息从单个队列中出列。只是想确保这会起作用，因为 MSMQ 有时的行为与我预期的不同。

WCF MSMQ 中有没有办法知道我是否正在处理事务中的最后一条消息？

我做了很多搜索，我发现有一个属性IsLastInTransaction，但是这个属性在 Class 中不可用，MsmqMessage<T>它只在System.Messaging.Message

任何人都知道我如何确定这是否是交易中的最后一条消息。

我正在尝试使用 win32com 库从 Python 中使用 MSMQ，类似于此示例。我可以将消息放入队列，但在这种情况下它是一个事务队列，所以我需要围绕消息发送创建一个事务。基本上我正在尝试使用 COM 在 python 中执行此VB 示例。

我不知道如何让交易发生：

给出：

如何开始交易？我在正确的轨道上吗？

如果使用 MSMQ 3.0 或 4.0：

我完全理解以下不是使用队列的常见或“正确”方式，但重点是立即解决特定问题。

是否可以在同一个事务中执行从远程队列的读取和对同一个远程队列的写入？执行此操作的应用程序是唯一的作者，但不是唯一的读者。鉴于使用支持远程事务读取的 MSMQ 版本。这种使用队列的方式有什么问题吗？

嘿伙计们，我是 android 开发的新手，我很好奇在服务器上的 android 应用程序上启用推送通知的“最佳”或最习惯的方式是什么。

我一直在网上阅读，并看到人们实现推送通知服务的两种主要方式是使用 MQTT 和 C2DM。任何人都可以详细说明这些或其他可用的服务，这些服务是实现推送通知的最佳解决方案。

我有以下代码，不是那么慢，也不是那么快。有没有办法改善这一点？我目前在 5 到 10 秒内收到 1000 条消息，我认为这还不理想。

请与处理器无关的答案，我的意思是配置方面如何使其更快

我不幸删除了MSMQ的系统文件，

现在我无法从队列发送和接收消息。

如何恢复被删除的文件？

视窗服务器 2012

MSMQ 6 工作组模式

我们在尝试恢复发送到事务死信队列的 MSMQ 消息时遇到问题。我们已经尝试将它们移动到出站队列，消息似乎发送良好（即使事件日志也是如此）但它永远不会到达目标队列。

经过反复试验，我们已经弄清楚如何将它们放到同一服务器上的另一个队列中，而不是放到远程服务器上的目标队列中。我们不想再丢失消息。有人对我们如何传递这些信息有任何建议吗？

谢谢，

大卫

我通过 Windows 服务运行 .exe，该服务从私人队列中读取消息。该服务一切正常且稳定，但有时服务会停止（它实际上并没有停止，但它没有处理任何内容。服务状态仍然是“已启动”，我需要手动重新启动它）。

这个不经常出现，但分析.exe文件的内存转储，我发现这么多线程遇到了异常。

异常对象：0000000001436120 异常类型：System.Messaging.MessageQueueException 消息：外部组件已引发异常。

知道为什么服务会遇到此异常吗？提前致谢

I have a Windows service that processes a private, local message queue (MSMQ). When it starts, it registers an event handler for PeekCompleted on the queue, and it then calls the asynchronous BeginPeek() to wait for a message to arrive.

Once a message arrives, my goal is to obviously process that message. My code currently has a queue.Receive() method to get the message, contained within a transaction so the message gets put back on the queue in case of errors during processing. BeginPeek() is called again to restart the cycle.

Do I, at any point, need to call EndPeek() on the queue ?

Maybe to avoid memory leaks, like this question alludes to ? I'm pretty sure I don't have to, but the documentation isn't very clear on that. It just doesn't feel 100% right to 'begin' something without 'ending' it :)

Btw: I could replace the Receive() line with Message msg = q.EndPeek(asyncResult.AsyncResult), which equally fetches me the message, but it doesn't remove the message from the queue.