When you install a new WebSphere® MQ network,
you can tune the installation for working with WebSphere Application Server. If you have an
established WebSphere MQ network,
you can choose whether to modify some of the settings for better interoperation.
About this task
This topic provides installation instructions for setting
up a new WebSphere MQ installation
to interoperate with WebSphere Application Server.
If you have an established WebSphere MQ network,
treat this task as a source of tips to tune your existing WebSphere MQ installation.
Procedure
- Install a supported version of WebSphere MQ, as described in the installation
instructions provided with WebSphere MQ.
To identify the supported version of WebSphere MQ, see the following article: Detailed system requirements page.
You should
not install Rational® Application
Developer and WebSphere Application Server on
the same machine when using WebSphere MQ.
For
other installation prerequisites, see the Quick Beginnings section
for your platform, in the WebSphere MQ information
center.
- Follow the WebSphere MQ instructions
for verifying your installation setup.
- Configure WebSphere Application Server and WebSphere MQ to interoperate effectively.
For information about the prerequisites and requirements
for effective interoperation, see the following technote: Information about using the WebSphere MQ messaging provider
for WebSphere Application Server Version
8.0.
Optional: Run the dltmqlnk WebSphere MQ control command. If
your application server is 64 bit, you must run the dltmqlnk WebSphere MQ control command as root
before applications are able to connect to a queue manager using a BINDINGS transport
type. The command must be rerun each time a WebSphere MQ fix pack is installed. For
more information, see the Implications of a 64-bit queue manager section
of the WebSphere MQ information center.
- Configure the WebSphere MQ messaging
provider with native libraries information.
To connect
to a WebSphere MQ queue manager or
queue-sharing group in bindings mode, the WebSphere MQ messaging provider needs
to know where to load native libraries from. For more information,
see Configuring the WebSphere MQ messaging provider with native libraries information.
- Optional: At Cell scope or Node scope, set the WebSphere Application Server MQ_CLEAR_MQ_FROM_OSGI_CACHE_ON_SHUTDOWN
environment variable to True. This
allows application server startup to automatically take account of
changes that are made to the MQ_INSTALL_ROOT environment variable
and WebSphere MQ JMS client libraries
while the application server is stopped.
If you do not set this
variable, you must restart the application server a second time after
any changes of this type, to enable the application to perform messaging
by using the WebSphere MQ messaging
provider.
Attention: If you set the MQ_CLEAR_MQ_FROM_OSGI_CACHE_ON_SHUTDOWN
environment variable, the startup time might increase because, on
startup, each application server needs to initialize an additional
state associated with
WebSphere MQ installation.
For
any change in the WebSphere MQ product
(such as a PTF upgrade), you must restart WebSphere Application Server and all nodes.
Optional: Set the WebSphere Application Server MQ_USE_BUNDLE_REFERENCE_INSTALL
environment variable to True. When
this variable is set to True, the WebSphere
MQ JMS bundle is installed using a reference installation.![[IBM i]](../images/iseries.gif)
The OSGi framework shares a storage area on
disk. Because all servers of the installation use this storage area,
multiple servers in the installation might read and or write data
to this storage area concurrently, causing resource contention. The
likelihood of a contention scenario occurring increases if the MQ_CLEAR_MQ_FROM_OSGI_CACHE_ON_SHUTDOWN
variable is set to True. Setting the MQ_USE_BUNDLE_REFERENCE_INSTALL
variable to True causes the WebSphere MQ JMS
bundle to be installed using a reference installation, thereby avoiding
the need for the OSGi framework to persist the WebSphere MQ JMS bundle
file to the shared storage area. Instead, each server creates a unique
bundle file for its use
The OSGi framework shares
a storage area on disk. Because all servers of the installation use
this storage area, multiple servers in the installation might read
and or write data to this storage area concurrently, causing resource
contention. The likelihood of a contention scenario occurring increases
if the MQ_CLEAR_MQ_FROM_OSGI_CACHE_ON_SHUTDOWN variable is set to True.
Setting the MQ_USE_BUNDLE_REFERENCE_INSTALL variable to True causes
the WebSphere MQ JMS bundle to be installed using a reference installation,
thereby avoiding the need for the OSGi framework to persist the WebSphere
MQ JMS bundle file to the shared storage area. Instead, each server
and controller creates a unique bundle file for its use.
What to do next
You are now ready to configure a messaging provider. If
your business uses WebSphere MQ,
and you want to integrate WebSphere Application Server messaging applications
into a predominantly WebSphere MQ network,
the WebSphere MQ messaging provider
is the natural choice. However, there can be benefits in using another
provider. If you are not sure which provider combination is best suited
to your needs, see Choosing messaging providers for a mixed environment.
To
create WebSphere MQ messaging provider
resources, see Configuring JMS resources for the WebSphere MQ messaging provider.