在 MSMQ 中查找旧消息
我这个场景有两个队列。 “错误”和“我的队列”。
消息被转储到 MyQueue 并从那里进行处理。如果失败，它们将被移至错误队列。 管理部门可能会将消息移回到 MyQueue 中以供再次处理。
我的任务是扫描/查看两个队列以查找并计算已经循环超过一小时的所有消息。
似乎
message.SentTime
message.ArrivedTime
两者都没用，因为每次消息进入队列时它们都会更新。
解决方案是在消息正文中放置时间戳，但这需要我打开所有消息以确定消息是否是“旧的”。
还有更好的选择吗？
I this scenario there are two queues. "Error" and "MyQueue".
The messages are dumped into MyQueue and processed from there. If they fail they are moved to the Error queue.
An administration might move a message back into the MyQueue for processing again.
My task if to scan/peek the two queue to find and count all the messages that has been cycling around for more than one hour.
It seems that
message.SentTime
message.ArrivedTime
are both useless, since they are updated each time the message enters a queue.
On solution would be to place an timestamp in the body of the message, this would however require me to open all messages to determine if the message is "old".
Any better alternatives?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
问题在于，在队列中循环的消息不是同一个消息。 “移动”消息通常是删除原始消息并根据原始内容创建新消息，这就是为什么您不能使用发送和到达时间。
移动的消息每次都有新的唯一 MessageID 值吗？如果没有，那么您可能可以生成一个与 MessageID 与其最初创建时间相匹配的表。
干杯
约翰·布瑞克威尔
The problem is that it is not the same message cycling round the queues. "Moving" a message is normally deleting the original and creating a new one based on the original contents, which is why you can't use the sent and arrived times.
Do the moved messages have new unique MessageID values each time? If not then maybe you could generate a table matching MessageID to the time it was initially created.
Cheers
John Breakwell
您可以使用 Message 类的 AppSpecific 属性来实现此目的。不幸的是它是一个 32 位整数；如果它很长，您可以将 DateTime.Ticks 存储在那里，然后使用它作为您需要计算消息存在多长时间的时间戳。
您可能会丢失 Ticks 中的一些位以将值适合 AppSpecific，如下所示：
这为您提供了秒级精度，我认为这足以满足您的情况...但是您不能使用内置的 DateTime 或 TimeSpan 方法如果您这样做，则从 Ticks 转换回来，因此您必须手动转换，或者只计算
Now与此值之间的增量。You might be able to use the
AppSpecificproperty of the Message class for this. Unfortunately it's a 32-bit integer; if it were a long you could store DateTime.Ticks there and then use that as the timestamp you need to calculate how long the message has been around.You could lose some of the bits in Ticks to fit the value into AppSpecific like this:
This gives you second-scale precision which I assume is enough for your case... however you can't use the built-in DateTime or TimeSpan methods that convert back from Ticks if you do this, so you'll have to convert manually, or just calculate the delta between
Nowand this value.