我配置的两个队列管理器(运行在Redhat Linux上的WebSphere MQ v7.1)之间的发送方和接收方通道经常出现故障。知道为什么吗?如何调试?谢谢
通道预计会关闭。这个想法是,只要有交通,他们就会保持活跃,然后超时。假设它们被配置为触发,XMitQ上出现的消息会导致通道再次启动。
原因是,如果被网络故障或其他不利事件中断,触发的信道通常会重新启动。但是,如果通道被配置为全天候运行,那么它停止的唯一方式是由于这些不良事件之一,这增加了重新启动通道需要人工干预的可能性。另一方面,超时的频道可以在不活动时经受住各种恶劣的网络事件。允许它在不使用时超时,从而提高了信道的整体可靠性。
那么,如何触发通道呢?确保传输队列包含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
属性的值),因此通常实际上会运行。
处于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的东西来默认禁用它们,因此如果您想在通道上使用keepality,则必须在QMgr调优中启用它,如下所述。
有关配置详细信息,请参阅信息中心的触发通道。如果您想了解有关内部结构和调优的更多信息,请参阅SupportPac MD0CWebSphere MQ-Keeping Channels Up and Running。(SupportPac有点过时,但调整原则仍然适用。如果存在差异,信息中心是权威版本。)
如果您想保持频道连续运行,请设置DISCINT(0)
,但请记住,触发仍然是首选选项。一些商店需要最大限度地减少营业日的响应时间,因此将DISCINT
设置为允许频道在夜间超时但通常保持全天运行的值。如果由于某种原因,您设置了触发权限,并且通道在DISCIINT
之前关闭,您应该能够在错误日志中查看原因。它们位于errors
下的QMgr目录中。例如,在UNIX/Linux上,它们位于/var/mqm/qmgrs/qmgrname/errors
中,而在Windows上,默认位置为C:Program Files(x86)WebSphere MQQMgrsqmgrnameerrors
。查找名为AMQERR??.LOG
的文件,其中??
=01
、02
或03
。日志在01
是当前的、02
是下一个的位置轮换,依此类推。如果您有一个非常繁忙的QMgr,您需要在通道关闭时立即捕获这些日志,否则它们可能会滚动。