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.

About these ads