In MQSeries 5.2 and previous releases, runmqlsr ran each inbound connection as a new thread within itself. If runmqlsr ran out of resources (memory, threads, file descriptors), then it would not accept any new connections. This massively threaded approach worked well on systems with a limited number of channels, but on very busy systems it was necessary to set up multiple listeners and balance connections across them.
The inetd daemon starts a new amqcrsta process for each inbound connection. There is no chance an amqcrsta responsible for only one channel will run out of resources, so even the busiest of queue managers requires only a single port in inetd. However, this massively unthreaded approach means that busy systems may have hundreds of amqcrsta processess, forcing administrators to increase maxuproc. Inetd has no idea when the queue manager is inactive, so it will start amqcrsta processes even when the queue manager is shut down.
WebSphere MQ 5.3 removed the listener scalability problem once and for all. Rather than running each inbound connection as a thread within itself, runmqlsr now passes connections to one of the amqrmppa channel pooling processes. These amqrmppa’s are threaded, but not massively so. This means they do not exhaust per-process resources or force administrators to increase maxuproc. The listener will start new amqrmppa processes as needed, so a single listener can now handle an unbounded number of connections. The listener is aware of the queue manager’s status at all times, so it is also very quick to deny connections when the queue manager is down.
This is also published on an FAQ page on the IBM Partnerworld Support site.
If you’ve not seen the site before, it is worth taking a look as they have some interesting items about a number of IBM products, including a whole section on WebSphere MQ.
6 comments
Comments feed for this article
July 24, 2007 at 3:01 am
Ted
Good post. I am at a stage where we are about to choose inetd or runmqlsr for our MQ cluster queue managers. This post gave was just what I needed!
July 26, 2007 at 4:52 am
Glenn
In MQ 5.3 and previous versions runmqlsr needed to be started as a separate process when the queue manager was started up. This inconvenience led to inetd being a popular alternative. The port configuration in /etc/services and /etc/inetd.conf was very easy and there was no need to worry about starting a separate listener process and ensuring that it kept running. MQ 6.0 is a different story, the listener can now be defined as an internal object in the queue manager, eg. define listener(qmgrname.LISTENER) trptype(TCP) control(QMGR) port(1414).
July 26, 2007 at 10:41 pm
Anonymous
Is it worth mentioning that runmqlsr is ‘replaced’ by a listener qmgr object in v6? (runmqsc DEF LISTENER / START LISTENER / DIS LSSTATUS)
July 27, 2007 at 1:47 am
Glenn
I mentioned it at the end of my post. The runmqlsr process is still there, but its now owned by the amqzmgr0 process [on Windows at least], along with amqpcsea (command server) and runmqchi (channel initiator).
November 23, 2007 at 1:37 pm
Anonymous
mqlsr is much better … inetd simply cannot handle thousands of simultaneously initiated connections (well, on Solaris anyway) … mqlsr does it easily.
October 24, 2008 at 7:55 pm
markdleonard
Use of the threaded listener does have its risk. For instance, if an error is encountered that causes the pool process to die (yes, that does happen), you will lose all of your channels being serviced by that pool. For cluster channels, the default is for them to be managed by the pool process.
For critical cluster channels, I have been changing them to start a separate process. That way, they are isolated from any other channel that can cause an issue.