12.4. Map Client Connections to Broker Instances

download PDF

Map Client Connections to Broker Instances

The MQ Gateway includes a configuration PID, io.fabric8.gateway.detecting. It sets the following properties:
 # configures the protocol detecting gateway


The defaultVirtualHost setting is used to specify the broker group name to be used by default for all clients. For example, if you have a Fabric broker group called us-east, with one or more broker instances running under this group (created using mq-create -group us-east). You can configure defaultVirtualHost to be us-east using the setting defaultVirtualHost=us-east.

How to Connect to a Specific Broker on the MQ Gateway

You can map to a broker group other than the default specified in defaultVirtualHost.
For example, if you had a broker group called us-west, set up in the same way as us-east above, you can map directly to it by configuring the MQ Gateway in the following way:
  1. Set up the Fabric broker group us-west using mq-create -group us-west
  2. Add the Fabric broker group name us-west as a virtual hostname for the machine that runs your MQ Gateway. This will require proper DNS configuration so that this virtual hostname can be resolved by any client.
  3. When your broker clients contact the MQ Gateway, use the hostname us-west in the broker url. For example,
The Gateway will map the request it receives via the virtual hostname us-west to one of your broker instances in the broker group us-west.
An alternative approach to that shown above is to define multiple instances of MQ Gateway. Configure each instance to a different default broker group in defaultVirtualHost and have broker clients explicitly connect to the instance of MQ Gateway that will bridge clients to the specific broker group.
For OpenWire only, you can use the following parameter to specify which broker group you want to be connected to:
If this command parameter is not specified, then the request is directed to the value in defaultVirtualHost.

MQ Gateway Client Connections for For Openwire and STOMP

An MQ Gateway can have its services exposed over multiple host names. When it receives a connection request, it uses the host the client was trying to connect to to look up a broker fabric group by the same name. The client is then connected to one of the brokers in the group that supports the protocol the client is connecting with. If the host the client is trying to connect to cannot be determined or does not match any of the fabric broker groups, then the client will be connected to a broker group that matches the defaultVirtualHost configuration.
AMQP and MQTT connections do not pass the hostname information so they always connect to the broker group that matches the defaultVirtualHost configuration.

Using MQ Gateway with SSL/HTTPS

The HTTP gateway does not directly support SSL/HTTPS, but the MQ Gateway does. If MQ Gateway is deployed alongside the HTTP Gateway, it will re-direct the decrypted http traffic to the HTTP Gateway.
Configuration changes need to be made to accommodate SSL/HTTPS. Edit io.fabric8.gateway.detecting to change the following properties:
trustStoreURL must be configured along with trustStorePassword
keyStoreURL must be configured along with keyStorePassword
You can also optionally configure the following properties:

Change the Listening Port on MQ Gateway

To change the listening port on MQ Gateway, edit io.fabric8.gateway.detecting using the following command:
profile-edit --pid io.fabric8.gateway.detecting/port=61619 gateway-mq  or
   gateway_mq profile -> configurations -> Detecting Gateway -> Bind Port on
Red Hat logoGithubRedditYoutubeTwitter


Try, buy, & sell


About Red Hat Documentation

We help Red Hat users innovate and achieve their goals with our products and services with content they can trust.

Making open source more inclusive

Red Hat is committed to replacing problematic language in our code, documentation, and web properties. For more details, see the Red Hat Blog.

About Red Hat

We deliver hardened solutions that make it easier for enterprises to work across platforms and environments, from the core datacenter to the network edge.

© 2024 Red Hat, Inc.