HTTP proxy servlet is deployed to a servlet container that is on a different machine to IBM Integration Bus with a network load-balancer for distributing work to several integration nodes

You can configure the HTTP proxy servlet for a deployment where the HTTP proxy servlet is deployed to a servlet container that is on a different machine to IBM Integration Bus, and the servlet container has a IBM MQ client link to the integration node queue manager. In this configuration, a network load-balancer is used to distribute work to several integration nodes.

In the following figure the HTTP proxy servlet is configured to load balance IBM MQ connections across multiple integration nodes. A network load balancer is required for this configuration.

When the HTTP proxy servlet is configured to connect to multiple integration nodes, the integration nodes must be identical clones of each other, which means that the same HTTP and SOAP flows are deployed with the same web addresses.

The HTTP proxy servlet sends the HTTP requests over the IBM MQ connections to distribute the load between the active integration node connections.

The diagram is described in the text.

The configuration is the same as that described in HTTP proxy servlet is deployed to a servlet container that is on a different machine to IBM Integration Bus, but the network load-balancer replaces the integration node machine. Configuration files cannot be used because there are several integration nodes behind one virtual IP address, and each one has a different configuration file. The HTTP proxy servlet loads information for each connection, and uses the relevant configuration information for each integration node.

In this configuration example, you must configure the following HTTP proxy servlet configuration parameters. For information about configuring the HTTP proxy servlet, see Configuring the HTTP proxy servlet.

  • Set useClientMode to true.
  • Set useQueueManagerDataInsteadOfConfigFile to * or the integration node queue manager name.
  • Set clientModeHostname, clientModeChannelName, and clientModePortNumber to the correct values as detailed in HTTP proxy servlet configuration parameters.

If failover is one of the reasons for deploying this configuration, it is recommended that you configure the following additional HTTP proxy servlet configuration parameters:

  • Set clientModeConnectRetryCount to a value equal or higher than the number of integration nodes. This setting ensures that a single failed server does not cause intermittent errors, even if the load-balancer does simple round-robin scheduling. The HTTP proxy servlet uses the first available integration node.
  • Set reconnectActiveLinksAge to a value less than the firewall timeout. This setting prevents the reuse of old connections that might have been discarded by firewalls between the HTTP proxy servlet and the load-balancer (or between the load-balancer and the integration nodes).

You can set testConnectionBeforeReuse to true as an alternative way to manage dropped IBM MQ connections between the HTTP proxy servlet and integration node queue managers. However, this option causes an MQINQ call to be performed before any attempt to send data to the integration node. If the MQINQ call fails, a new connection is established, and the data is sent over the new connection. Because the configuration adds another operation to the MQPUT and MQGET calls, it results in significant processing for every message; use this option only if no alternative options are available. For information about MQINQ, MQPUT, and MQGET calls, search for Function calls in the IBM MQ product documentation.

Before you configure, deploy, and test the HTTP proxy servlet, ensure that you understand the following concepts:
When you have gained an understanding of the HTTP proxy servlet concepts, read the following topics to help you configure, deploy, and test the HTTP proxy servlet: