【发布时间】:2014-04-02 05:06:19
【问题描述】:
我希望我的集成总线流实例能够将读取/写入切换到多个队列管理器,这些队列管理器都同时处于活动状态,都具有相同的队列定义。就像有一个多实例 QM,但在这种情况下 QM 不会相关,我想从 QM 中按顺序阅读。
一个干净的解决方案是每个流使用一个 JMSInput 节点,所以我正在徘徊是否可以通过使用 CCD 表来实现。
【问题讨论】:
标签: ibm-mq messagebroker
我希望我的集成总线流实例能够将读取/写入切换到多个队列管理器,这些队列管理器都同时处于活动状态,都具有相同的队列定义。就像有一个多实例 QM,但在这种情况下 QM 不会相关,我想从 QM 中按顺序阅读。
一个干净的解决方案是每个流使用一个 JMSInput 节点,所以我正在徘徊是否可以通过使用 CCD 表来实现。
【问题讨论】:
标签: ibm-mq messagebroker
对于在已知队列上侦听的任何事物(例如,在请求/回复场景中为请求提供服务的事物,如代理流的通常情况),通常的建议是它不会在队列之间进行故障转移.造成这种情况的原因有很多,但主要原因是这排除了事务性GET,并且最终可能会出现未提供服务的队列,其中消息会累积且未被处理。
尽管可以让服务器应用程序执行您所描述的循环,但CONNECT/DISCONNECT 操作比GET/@ 操作要很多昂贵987654325@ 操作。结果是,轮流为多个队列提供服务的流的执行速度比具有多个流实例的执行组慢几个数量级,其中每个流实例都指向不同的队列实例。
如果需要保护这些代理连接,通道可能会使用 TLS 和相互身份验证。这将CONNECT/DISCONNECT 的延迟复合到每次连接尝试最多一秒或更多。由于 TLS 握手只发生在连接上而不是每条消息上,这在“每个流一个队列”的正常模型中影响不大。但是,在循环连接方案中,您很幸运能够在每个队列中每秒收到 1 条消息。当然,任何 TLS 连接都是如此,而不是特定于 WMQ。
【讨论】:
我不这么认为。我相信通道的选择是在实例化 JMS Connection 对象时做出的,并且代理将缓存每个节点的单个 JMS 连接。只有在遇到表明连接断开的异常时,它才会尝试重新创建此连接。
所以我认为使用 CCDT 可以获得一些故障转移,但不是您正在寻找的那种负载平衡。
【讨论】: