【问题标题】:checking queue manager status through Visual Basic 6通过 Visual Basic 6 检查队列管理器状态
【发布时间】:2014-05-08 13:41:55
【问题描述】:

我必须在打开队列之前检查 IBM MQ 队列管理器的状态。 我必须通过检查 QMgr 是否处于活动状态来创建请求者应用程序,然后调用 put msg 或从 MQ 获取消息 是否可以检查状态,

请分享一些代码sn-ps。

谢谢

【问题讨论】:

  • 您需要更具体地提出您的问题,否则它很可能会被关闭。查看how to ask 寻求帮助。
  • Mani,更多细节会有所帮助。你到底想检查什么?如果您可以连接到 qmgr,那么它就可以(就状态而言)?
  • 我已投票决定关闭等待响应,以了解究竟是什么推动了在发送消息之前检查状态的要求。这闻起来很糟糕的设计。一个监控应用程序只是连接和查询东西。业务应用程序只是连接并尝试放置/获取消息并处理异常。将两者混合几乎总是不好的。

标签: vb6 ibm-mq


【解决方案1】:

您永远不必在打开队列之前检查 QMgr。正如我今天回复a similar question 一样,所提出的设计是一个非常非常糟糕的设计。效果是将异步消息传递回同步消息传递。这将消息生产者与消费者耦合在一起,引入了位置和解析依赖关系,破坏了集群,破坏了 WMQ 的负载分配和平衡,将网络拓扑嵌入到应用程序中,并使整个系统变得脆弱。请不要责怪 WMQ 在故意破坏除实际队列/出队操作之外的所有最佳功能后无法正常工作。

如果您的请求者应用程序正在检查 QMgr 是否处于活动状态,那么您最好使用多实例连接名称和一个由两个或多个功能等效的 QMgr 组成的层来访问集群。只要其中一个 QMgrs 启动,应用程序就会在它们之间循环,直到找到一个可以连接的地方。

如果您的响应应用程序正在检查 QMgr 是否处于活动状态,那么您最好更多尝试连接。响应程序应用程序绝不故障转移到不同的 QMgr,因为这样做会破坏事务性并可能使队列无人服务。相反,只需确保每个队列至少有两个来自本地响应程序应用程序的输入句柄,它们不会跨 QMgrs 进行故障转移。 (如果 QMgr 本身使用硬件集群或多实例 QMgr 进行故障转移也可以)。

如果意图是在将消息放在那里之前检查队列上是否有打开的输入句柄,那么更好的设计是让请求应用程序不关心消息路由到哪个队列实例,而是使用 WMQ 中内置的工具来要么重新启动丢失输入句柄的响应应用程序,要么在没有任何内容的情况下禁用队列。

【讨论】:

  • 谢谢 Rob,是否可以分享一些代码 sn-ps,这将提供有关在我可以启动任何 get 或 put 消息之前如何检查 Qmgr 状态的见解
  • 如果连接成功,说明状态良好,继续发消息。如果您在尝试放置消息时收到错误代码,该错误代码将告诉您放置失败的原因。还需要什么?为什么要在发送消息之前检查状态以及您要检查的具体内容是什么?
猜你喜欢
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2019-07-07
  • 1970-01-01
  • 2022-08-03
  • 2015-01-09
  • 1970-01-01
  • 1970-01-01
相关资源
最近更新 更多