使用JMS + CCDT文件连接到IBM MQ时的负载平衡问题 [英] Load balancing issue while connecting to IBM MQ using JMS + CCDT file

问题描述

我们正在尝试使用CCDT文件和JMS配置连接到IBMMQ. 我们可以连接到它，但是这里有一个问题:

We are trying to connect to IBMMQ using CCDT file and JMS configuration. We are able to connect to it but we have an issue here:

由于我们正在使用spring来设置CCDT文件的连接工厂，因此在应用程序启动时将其初始化一次，但是不幸的是，它一次只选择一个队列管理器，即它将所有消息发送到同一队列管理器，并且它不会实现负载平衡.

since we are using spring to set connection factory with CCDT file, this is initialized once at the start of the application, but unfortunately it picks only one queue manager at a time,i.e it sends all the messages to same queue manager and it does not load balance.

尽管我观察到了，但是如果我在每个请求之前手动设置了CCDT文件，那么它就能够负载均衡队列管理器，理想情况下，只要我将URL设置为CCDT文件，就可以确定队列管理器对我而言是否理想.这是错误的做法.我的期望是使用CCDT文件初始化连接工厂，然后此配置将能够自行实现负载平衡.

Though i observed, if i manually set the CCDT file before every request then its able to load balance the Queue Managers, ideally it looks to me Queue Manager is decided whenever i set the URL to CCDT file. which is wrong practice. My expectation was to initialize the connection factory with CCDT file and then this configuration will be able to load balance on its own.

您能帮我吗?

推荐答案

这是预期的行为. MQ不会对客户端进行负载平衡，而是通过连接来平衡它们.该连接是最耗时的单个API调用，并且在经过相互身份验证的TLS连接的情况下，可能需要几秒钟才能完成.因此，良好的应用程序设计将尝试连接一次，然后在会话期间保持该连接. JMS体系结构和Spring框架都希望采用这种模式.

This is the expected behavior. MQ does not load balance clients, it connection balances them. The connection is the single most time consuming API call and in the case of a mutually authenticated TLS connection can take seconds to complete. Therefore a good application design will attempt to connect once, then maintain that connection for the duration of the session. The JMS architecture and Spring framework both expect this pattern.

MQ提供负载分配的方式(再次，不是真正的 balancing ，而是循环的 distribution )是客户端将跳远连接到了集群目的地队列.发送到该群集目标队列的消息将在该队列的所有实例之间循环.

The way that MQ provides load distribution (again, not true balancing, but rather round-robin distribution) is that the client connects a hop away from a clustered destination queue. A message addressed to that clustered destination queue will round-robin among all the instances of that queue.

如果它是一个请求答复应用程序，则在这些群集队列实例上侦听请求的事物将使用请求消息中的Reply-To QMgr和Reply-To Queue名称来处理答复消息.在这种情况下，如果请求者失去连接，则可以将QMgr故障转移到QMgr.集群队列上的记录侦听系统通常不会跨队列管理器进行故障转移，以确保为所有队列实例提供服务，并且是由于事务恢复.

If it is a request-reply application, the thing listening for requests on these clustered queue instances addresses the reply message using the Reply-To QMgr and Reply-To Queue name from the requesting message. In this scenario the requestors can fail over QMgr to QMgr if they lose their connection. The systems of record listening on the clustered queues generally do not fail over across queue managers in order to ensure all queue instances are served and because of transaction recovery.

最简单的答案是，一般而言，CCDT和MQ客户端不是发生MQ负载分布的 .客户端应建立连接并保持尽可能长的时间.客户端重新连接和CCDT仅用于连接平衡.

Short answer is that CCDT and MQ client in general are not where MQ load distribution occurs. The client should make a connection and hold it as long as possible. Client reconnect and CCDT are for connection balancing only.

负载分配是MQ集群的功能.它需要一个群集队列的多个实例，并且这些实例通常是与放置消息的客户端应用程序之间的网络跳转.

Load distribution is a feature of the MQ cluster. It requires multiple instances of a clustered queue and these are normally a network hop away from the client app that puts the message.

这篇关于使用JMS + CCDT文件连接到IBM MQ时的负载平衡问题的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！