Connection Services

You use connection-related properties to configure and manage the physical connections between a broker and its clients. As shown in Figure 1–6 both application clients and administration clients can connect to the broker. The JMS specification does not dictate that providers implement any specific wire protocols. Message Queue connection services, used by application clients and administration clients to connect to the broker, are currently layered on top of TCP, TLS, HTTP, or HTTPS protocols. TLS (Transport Layer Security) is a successor to and compatible with SSL (Secure Socket Layer).

There are two general types of connection services:

• NORMAL: Services that provide JMS support and allow clients to connect to the broker (jms, ssljms, http, or https) and are layered on top of TCP, TLS, HTTP, or HTTPS protocols, respectively. (Services layered on top of HTTP allow messages to pass through firewalls.)

• ADMIN: Services that allow administrators to connect to the broker ( admin, ssladmin) and are layered on top of TCP or TLS protocols.

Connection services are available through dedicated ports that can be dynamically assigned by the broker’s Port Mapper (see Port Mapper Service) or statically assigned by the administrator. By default, when you start the broker, the jms and admin services are up and running. Additionally, you can configure a broker to run any or all of the connection services.

Each connection service is multi-threaded, supporting multiple connections, and each service supports specific authentication and authorization (access control) features. See Security Services for more information.

Should a connection fail, the Message Queue service can automatically retry connecting the client to the same broker or to a different broker if this feature is enabled. For more information, see the description of the automatic reconnect feature in Appendix B, Message Queue Features

The connections provided by Message Queue connection services can be configured to specify which brokers to connect to, how to handle reconnection, message flow control, and so on. For additional information about how connections can be configured, see Connection Factories and Connections.

Connection configuration can be performed by both administrators and in client application code:

• An administrator creates connection factory administered objects that encapsulate connection behaviors. In addition, an administrator can use 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 interfaces are used. An administrator can also specify a ping interval to test whether the client is accessible; this is useful in managing resources.

• Client code can instantiate configuration factory objects and set their attributes to achieve desired connection behaviors. These attributes specify non-default connection services, hosts, ports, a list of brokers to connect to in case reconnection is required, and reconnection behavior. The client can also specify a ping interval to test for failed connections.

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.

Port Mapper Service

Connection services are dynamically assigned a port by a common Port Mapper service 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.

Thread Pool Management

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.