WebSphere Message Broker, Version 8.0.0.7 Operating Systems: AIX, HP-Itanium, Linux, Solaris, Windows, z/OS

See information about the latest product version

Example proxy servlet configuration scenarios

The configuration of the proxy servlet varies depending on the configuration in which it is deployed.

The proxy servlet configuration depends upon the deployment in which the proxy servlet is used. The following sections describe some common scenarios and the proxy servlet configuration parameters that are required.

Scenario 1: The Web servlet container is on the same server as WebSphere® Message Broker

In this configuration example, you must configure the following proxy servlet configuration parameters:

  • Set useClientMode to false.
  • Set useQueueManagerDataInsteadOfConfigFile to "".
  • Set configFile to the location of the configuration file.

The servlet reads the queue manager name from the configuration file and then attempts to connect to that queue manager.

Scenario 2: The Web servlet container is on a different server to WebSphere Message Broker with an WebSphere MQ client link to the broker queue manager

In this configuration example, you must configure the following proxy servlet parameters:

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

The servlet attempts to connect to the remote queue manager for the broker, reading the required node configuration data from the broker from the WebSphere MQ client connection. For the connection to succeed, you must start the SYSTEM.DEFAULT.LISTENER.TCP listener in the remote queue manager.

Note: You can copy the configuration file from the broker server to the Web servlet container server, and then set the following proxy servlet configuration parameters:
  • Set configFile to the location of the configuration file that you copied from the broker server.
  • Set useQueueManagerDataInsteadOfConfigFile to "" to force the servlet to read the configuration file.

However, you must then copy the configuration file every time it is changed by the broker.

Scenario 3: The Web container is on a different server to WebSphere Message Broker with its own queue manager and a WebSphere MQ channel link to the broker queue manager

This configuration example is similar to scenario 1 in that client mode is not used, but you must set the following proxy servlet configuration parameters:

  • Set useClusterMode to true.
  • Set clusterModeQueueManagerName to the queue manager of the Web servlet container.
  • Set clusterModeReplyToQ to a queue that exists on that queue manager.

The servlet tries to open the queue SYSTEM.BROKER.WS.INPUT on the specified queue manager by using the queue manager name from the configuration file. Therefore, you must set up channels and transmit queues beforehand to ensure that the messages arrive on the broker queue manager.

You must copy the configuration files from the broker server in this scenario.

Scenario 4: The Web servlet container is on a different server to WebSphere Message Broker with an WebSphere MQ client link to the broker queue manager but uses a network load-balancer for distributing work for several brokers:

The configuration is the same as scenario 2, but the network load-balancer IP replaces the broker server. In general, configuration files cannot be used because there are several brokers behind one virtual IP address, and each one has a different configuration file. The servlet loads information on a per-connection basis, and uses the correct configuration information for each broker.

In this configuration example, you must configure the following proxy servlet configuration parameters:

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

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

  • Set clientModeConnectRetryCount to a value equal or higher than the number of brokers. This setting ensures that a single failed server does not cause intermittent errors, even if the load-balancer does simple round-robin scheduling. The servlet uses the first available broker.
  • 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 servlet and the load-balancer (or between the load-balancer and the brokers).

You can set testConnectionBeforeReuse to true as an alternative way to handle dropped WebSphere MQ links between the Web servlet container and broker queue managers. However, this option causes an MQINQ to be performed before an attempt to send any data to the broker. If the MQINQ 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, it results in a significant overhead for every message; use this option only if no alternative options are available.

To finish completing the proxy servlet configuration, see Configuring the proxy servlet.

For information about all the proxy servlet configuration parameters, see Proxy servlet configuration parameters.

Notices | Trademarks | Downloads | Library | Support | Feedback

Copyright IBM Corporation 1999, 2016Copyright IBM Corporation 1999, 2016.

        
        Last updated:
        
        Last updated: 2016-05-23 14:46:36


Reference topicReference topic | Version 8.0.0.7 | ac69431_