You use connection-related properties to configure and manage the physical connections between a broker and its clients. Connection services available for Message Queue clients are introduced in Connecting to the Broker, which describes available connection services: their name, type, and underlying protocol. Connection services are multithreaded and available through dedicated ports that can be dynamically assigned by the broker’s port mapper or statically assigned by the administrator. By default, when you start the broker, the jms and admin services are up and running.
Because there are two parties to every connection, connection configuration occurs on both sides and needs to be coordinated:
The client must configure certain attributes of the connection factory object to ask for non-default connection services, hosts, and ports; to specify a list of brokers to connect to in case reconnection to a different broker is required; and to configure reconnection behavior. The client can also specify a ping interval to test for failed connections.
The administrator, in turn, uses broker properties to activate non-default connection services, to assign static ports if required, to configure threading, and to specify a host to connect to if multiple network cards are used. The administrator can also specify a ping interval to test whether the client is accessible; this is useful in managing resources.
A client can connect to the Message Queue service through a firewall. This can be done either by having the firewall administrator open a specific port and then connecting to that (static) port or by using the HTTP or HTTPS service as summarized in Appendix B, Message Queue Features.
Each connection service also supports specific authentication and authorization features. See Security Services for more information.
Connection services are dynamically assigned a port by a common Port Mapper that resides at a the broker’s main port, 7676. When the Message Queue client runtime sets up a connection with the broker, it first contacts the Port Mapper, requesting a port number for the connection service it has chosen.
You can override the Port Mapper by assigning a static port number for the jms, ssljms, admin and ssladmin connection services when configuring these services. However, static ports are generally used only in special situations, such as in making connections through a firewall and are not generally recommended.
Each connection service is multithreaded, supporting multiple connections. The threads needed for these connections are maintained by the broker in a pool. How they are allocated depends on the values you specify for the minimum and maximum thread values, and on the threading model you choose.
You can set broker properties to specify a minimum number and maximum number of threads As threads are needed by connections, they are added to the thread pool for the service supporting that connection. The minimum specifies the number of threads available to be allocated. When the available threads exceeds this minimum threshold, the system will shut down threads as they become free until the minimum is reached again, thereby saving on memory resources. Under heavy loads, the number of threads might increase until the pool’s maximum number is reached; at this point, new connections are rejected until a thread becomes available.
The threading model you choose specifies whether threads are dedicated to a single connection or shared by multiple connections:
In the dedicated model, each connection to the broker requires two threads: one for incoming messages and one for outgoing messages. This limits the number of possible connections but provides high performance.
In the shared model, connections are processed by a shared thread when sending or receiving messages. Because each connection does not require dedicated threads, this model increases the number of possible connections, but adds some overhead for thread management and thereby impacts performance.