WebSphere MQ v7.1 通道关闭

Question

我配置的两个队列管理器（在 Redhat Linux 上运行的 WebSphere MQ v7.1）之间的发送方和接收方通道经常出现故障。知道为什么吗？我该如何调试这个？谢谢。

Answer 1

频道预计会下降。 这个想法是，只要有流量，它们就会保持活跃，然后超时。 假设它们已配置为触发，XMitQ 上出现的消息会导致通道再次启动。

这样做的原因是，如果网络故障或其他不良事件中断，触发通道通常会重新启动。 但是，如果通道配置为 24x7 保持运行，则其停止的唯一方式是由于这些不利事件之一，并且这增加了需要人为干预来重新启动通道的可能性。另一方面，超时的通道可以在不活动期间发生的各种令人讨厌的网络事件中幸存下来。 允许其在不使用时超时，从而提高通道的整体可靠性。

那么如何触发通道呢？ 确保传输队列包含

TRIGGER

、

TRIGTYPE

、

TRIGDATA

和

INITQ

属性。 例如，定义一个到

JUPITER

QMgr 的传输队列：

DEF QL(JUPITER) +
    USAGE(XMITQ) +
    TRIGGER +
    TRIGTYPE(FIRST) +
    TRIGDATA('MYQMGR.JUPITER') +
    INITQ(SYSTEM.CHANNEL.INITQ) +
    REPLACE

这组变量中唯一的变量是

TRIGDATA

，其中包含为该 XMitQ 提供服务的通道的名称。

当然，通道启动器必须正在运行，但在现代版本的 WMQ 中，它默认启动（基于队列管理器的

SCHINIT

属性的值），因此通常 will 实际上正在运行。

处于

STOPPED

状态的通道不能被触发。 默认情况下，

STOP CHL

命令使用

STATUS(STOPPED)

，因此大多数时候手动停止通道可以防止触发。 如果您想以重新启动通道的方式停止通道（例如测试触发），请使用

STOP CHL(CHLNAME) STATUS(INACTIVE)

命令。 如果通道已处于

STOPPED

状态，请发出

START CHL

命令使其立即启动，或使用

STOP CHL(CHLNAME) STATUS(INACTIVE)

将状态从

STOPPED

更改为

INACTIVE

，而不启动它。

一旦通道启动，通道的

DISCINT

属性将决定超时之前它将运行多长时间。 该值以秒为单位，默认为 600，即 10 分钟。

DISCINT

、

KAINT

和

HBINT

结合起来确定通道何时关闭。 请注意，TCP 规范要求使用 keepalive 的事物默认禁用它们，因此如果您想在通道上使用 keepalive，您必须在 QMgr 调整中启用它，如此处所述。

请参阅信息中心的触发通道，了解更多配置详情。 如果您想了解有关内部结构和调优的更多信息，请查看 SupportPac MD0C WebSphere MQ - 保持通道正常运行。 （SupportPac 有点过时，但调整原则大部分仍然适用。如有差异，信息中心是权威版本。）

如果您想保持通道持续开启，请设置

DISCINT(0)

，但请记住，触发仍然是首选选项。 一些商店需要最大限度地减少工作日的响应时间，因此将

DISCINT

设置为允许通道在夜间超时但通常保持全天运行的值。 如果由于某种原因您正确设置了触发并且通道在

DISCIINT

之前关闭，您应该能够在错误日志中检查原因。 它们位于

errors

下的 QMgr 目录中。 例如，在 UNIX/Linux 上，它们位于

/var/mqm/qmgrs/qmgrname/errors

，而在 Windows 上，默认位置为

C:\Program Files(x86)\WebSphere MQ\QMgrs\qmgrname\errors

。 查找名为

AMQERR??.LOG

的文件，其中

??

=

01

、

02

或

03

。 日志在

01

为当前位置、

02

为下一个位置轮换，依此类推。 如果您的 QMgr 非常繁忙，您需要在通道关闭后立即捕获这些信息，否则它们可能会滚落。

Answer 2

我在这里很困惑，所以如果在传输队列中启用了触发器，但在任何消息到达队列之前，发送者通道由于 DISCINT 中映射的短时间值而变得不活动，假设 2 秒 DISCINT(2)。

那么，在上述场景中，如果有消息到达传输队列，发送者通道是否会再次激活？