There are two ways to establish a TCP connection to a queue manager in Websphere MQ namely:

1. Use the native support provided by the OS (for example Solaris)
2. Use the service/feature provided by Websphere MQ

Native support provided by the OS (Solaris Unix)

The one provided by the OS Solaris is typically configured as a service in “inetd” daemon meaning for every incoming connection to a queue manager the “inetd” daemon starts a process. This unthreaded approach means that for busy queue managers there might be hundreds or thousands of such processes started. How many processes can the OS really start ?, is controlled by the kernel parameter “maxuproc” in Solaris Unix. For example if this setting is 29,000 (typically is in this range) per user and if the incoming messages are in the range of 30K per time unit, then a possibility exists that the MQ admin user i.e. “mqm” would max out on the # of processes that can be started.

Feature provided by Websphere MQ
The “inetd” daemon approach mentioned above was used in MQ v 5.2 and earlier versions limiting the listener scalability. In MQ v 5.3, IBM introduced and recommends using the command “runmqlsr” which passes connections to channel pooling processes. The channel pooling processes are threaded and do not exhaust per-process, per-user resources thereby removing the limitation imposed by Solaris kernal parameter “maxuproc”. A single listener starts a new threaded channel pool process when needed and thus can handle an unbounded number of connections. Whereas the “inetd” daemon approach creates a process for every inbound connection leading to orphaned processes, when a queue manager is inactive. This is another maintenance overhead that can be saved by using “runmqlsr”.