使用 JScript 查看 MSMQ 传出队列

发布于 2024-09-13 04:07:53 字数 939 浏览 9 评论 0原文

我创建了一个脚本来监视一组队列,虽然它与远程专用队列完美配合,但它不适用于传出队列。我做了一个实验,从脚本中删除了除必要内容之外的所有内容,并创建了以下测试脚本:

var info = new ActiveXObject("MSMQ.MSMQQueueInfo");
info.FormatName = /*<Queue name>*/;

// 0x80 = MQ_ADMIN_ACCESS
// 0x20 = MQ_PEEK_ACCESS
// 0x00 = MQ_DENY NONE
var mq = info.Open(0x80 | 0x20, 0x00);

var msg = mq.PeekCurrent(false, true, 0); 
if (msg != null) {
    WScript.echo("message found");  
}
else
{
    WScript.echo("Nothing");
}
mq.close();

然后我在服务器上运行它,即使队列包含超过一千条消息,PeekCurrent 始终返回空值。如果我删除 MQ_ADMIN_ACCESS,它会尝试连接到远程专用队列并超时(如预期,因为它会导致消息累积)。如果我随后启动远程专用队列,它会从中正确读取消息。

出于好奇,我发现当使用 MQ_ADMIN_ACCESS 时,无论队列名称(即是否存在),info.Open 总是成功。例如,我输入“DIRECT=OS:Whatever\private$\RandomQueueName”,但没有收到任何错误。

我不是 MSMQ 专家(恰恰相反),所以我可能犯了一个明显的错误,但我看不到它。非常欢迎任何帮助。谢谢。

附带问题:是否可以查看远程传出队列?目前,该脚本正在我正在测试的传出队列所在的计算机上运行,​​但它并不是唯一具有这些队列的计算机。我想避免在任何地方部署脚本,我宁愿将其放在一个地方。谢谢。

I created a script to monitor a set of queues, and, while it works perfectly with Remote Private Queues, it doesn't work with Outgoing Queues. I made an experiment by removing everything but the essential from the script, and I created the following test script:

var info = new ActiveXObject("MSMQ.MSMQQueueInfo");
info.FormatName = /*<Queue name>*/;

// 0x80 = MQ_ADMIN_ACCESS
// 0x20 = MQ_PEEK_ACCESS
// 0x00 = MQ_DENY NONE
var mq = info.Open(0x80 | 0x20, 0x00);

var msg = mq.PeekCurrent(false, true, 0); 
if (msg != null) {
    WScript.echo("message found");  
}
else
{
    WScript.echo("Nothing");
}
mq.close();

I then ran it on the server and, even if the queue contains over a thousand messages, PeekCurrent always returns null. If I remove MQ_ADMIN_ACCESS it tries to connect to the Remote Private Queue and it times out (as expected, as it's down to let messages cumulate). If I then start the Remote Private Queue, it reads the message correctly from it.

Out of curiosity, I found out that info.Open always succeeds no matter the Queue Name (i.e. whether it exists or not) when MQ_ADMIN_ACCESS is used. For example, I typed "DIRECT=OS:Whatever\private$\RandomQueueName", and I didn't get any error.

I'm not an expert of MSMQ (quite the opposite), so I'm probably making an obvious mistake and I can't see it. Any help is more than welcome. Thanks.

Side question: is it possible to peek a Remote Outgoing Queue? At the moment the script is running on the machine where the Outgoing Queue I'm testing is located, but it's not the only one with these queues. I'd like to avoid deploying the script everywhere, I'd prefer to have it in a single place. Thanks.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

飘逸的'云 2024-09-20 04:07:53

我找到了两个问题的答案:

  • 我遇到的问题是由于我尝试监视作为群集资源组的一部分运行的 MSMQ 队列,而脚本在当前控制台下运行会议。要访问集群资源组内的队列,必须执行以下操作:

    1. 创建新的通用应用
    2. 运行 MSMQ 服务的组内的资源,并将其指向您的脚本。
    3. 在新资源的配置中,添加 MSMQ 服务作为依赖项。
    4. 确保“使用网络名称作为计算机名称”复选框已选中

完成后,您的脚本现在将连接到在群集组内运行的 MSMQ 服务。

  • 传出队列不是真正的队列,但可以被视为“消息列表,按它们注定要到达的队列分组”。因此,无法对其进行远程监控。这意味着,要监视它们,必须将执行此操作的脚本/应用程序部署在每台计算机上,并且在集群环境中,每个集群组中必须运行一个实例。如果有很多服务器,这会增加显着的开销,但可以通过创建集中式系统来克服。无论如何,这是一项艰巨的任务......

我希望我的发现对将来的人有用。 :)
回到披萨烘焙……

I found the answers to both my questions:

  • The issue I was having was due to the fact that I tried to monitor an MSMQ Queue which was running as part of a Cluster Resource Group, while the script was running under the current Console Session. To access a Queue inside a Cluster Resource Group, the following must be done:

    1. Create a new Generic Application
    2. Resource inside the Group where the MSMQ Service is running, and point it to your Script.
    3. In the Configuration of the new Resource, add the MSMQ Service as a dependence.
    4. Make sure that the checkbox "Use Network Name as Computer Name" is checked.

Done, your script will now connect to the MSMQ Service running inside the Cluster Group.

  • Outgoing Queues are not real Queues, but can be seen as a "list of messages, grouped by the Queue they are destined to". Therefore, they cannot be monitored remotely. This means that, to monitor them, the Script/Application which does it has to be deployed on each machine, and, in a clustered environment, an instance must run in each Cluster Group. This adds a significant overhead if there are many servers, but it can be overcome by creating a centralized system. Big task anyway...

I hope my findings will be useful to somebody in the future. :)
Back to pizza baking...

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文