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 removes 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.
http://www.developer.ibm.com/tech/faq/results/0,1322,1%253A401%253A416%253A1 48%253AGeneral,00.html#q148 -----Original Message----- From: MQSeries List [mailto:[EMAIL PROTECTED] Behalf Of Neil Casey Sent: Wednesday, July 20, 2005 8:06 PM To: [email protected] Subject: Re: Listener; runmqlsr vs amqcrsta within the inetd.conf file Hi Kieth, I would not expect that the threaded listener vs inetd listener would make a difference to client CPU usage. Given the change in platform, I would be tempted to investigate coded character sets and possible conversion issues. Is it possible that the MPE system was running the same CCSID as windows, meaning that no conversion was performed, but that AIX is running with a different CCSID? Regards, Neil Casey ____________________________________________________________________________ ______ Senior Systems Programmer Phone : +61 3 9886 2375 (x82375) Middleware Services MQ Support Mobile: +61 414 615 334 Cross Platform & Transaction Services Fax : +61 3 9886 2700 (x32700) Southern Star Technology Email : [EMAIL PROTECTED] This email is sent by or on behalf of the named sender identified above. If you do not wish to receive any email marketing material from this person in the future, please forward the contents of this email to [EMAIL PROTECTED] with the word "unsubscribe" in the subject box. If you do not forward the contents of this email with your unsubscription then it may not be able to be implemented. If you wish to unsubscribe from all central email marketing lists used by our business, please forward the contents of this email to [EMAIL PROTECTED] with the message "unsubscribe from all central email marketing lists" in the subject box. If you do not forward the contents of this email with your unsubscription then it may not be able to be implemented. The information contained in this email communication may be confidential. You should only disclose, re-transmit, copy, distribute, act in reliance on or commercialise the information if you are authorised to do so. Any views expressed in this email communication are those of the individual sender, except where the sender specifically states them to be the views of a member of the National Australia Bank Group of companies. Any advice contained in this e-mail has been prepared without taking into account your objectives, financial situation or needs. Before acting on any advice in this e-mail, National Australia Bank Limited recommends that you consider whether it is appropriate for your circumstances. If this e-mail contains reference to any financial products, the National recommends you consider the Product Disclosure Statement (PDS) or other disclosure document before making any decisions regarding any products. The National Australia Bank Group of companies does not represent, warrant or guarantee that the integrity of this communication has been maintained nor that the communication is free of errors, virus or interference. [EMAIL PROTECTED] COM Sent by: MQSeries To List [email protected] <[EMAIL PROTECTED] cc V.MEDUNIWIEN.AC.A T> Subject Re: Listener; runmqlsr vs amqcrsta within the inetd.conf file 21/07/2005 09:11 Please respond to MQSeries List <[EMAIL PROTECTED] V.MEDUNIWIEN.AC.A T> Neil, We are using aix 5.2 with MQ 5.3.......I apologize as I do not know the minor levels at this time (I can get them in the morning).......we originally migrated of the wintel platform altogether due to the instability of the 5.2 multi-threaded listener......inetd has been awesome for stability but a recent problem where a MPE based operating system MQ client application has experienced a significant cpu increase once it was redirected from the Wintel MQ 5.3 platform to an AIX based qmgr running inetd......... Were still not sure if its due to the type listener that is being used or the platform swap in general.......we went with AIX over Wintel for availabilty but we certainly don't want to increase client cpu utilization......... -------------------------- Sent from my BlackBerry Wireless Handheld ----- Original Message ----- From: MQSeries List [EMAIL PROTECTED] Sent: 07/20/2005 06:55 PM To: [email protected] Subject: Re: Listener; runmqlsr vs amqcrsta within the inetd.conf file Hi Kieth, are your problems with the threaded listener occuring in WMQ 5.3? and are your running any exits in your channels? Exactly what problems have you seen and on what platforms? My site found the 5.2 threaded implementation to be less than completely reliable, but we have been extremely happy with the 5.3 implementation. The one exception to this is some exits which are used by one application to journalise the messages as they flow through the channels. The exit does not behave correctly in the threaded environment, and tends to cause failures. Because it works with the inetd based channels, the users refuse to rewrite it, so I am stuck with it. (No time or budget for me to enhance it). IBM will push the threaded listener because its performance is significantly better than the inetd implementation. This is because of process instantiation overheads which the threaded listener avoids by using a pooling process to hold the threads for multiple channels. Regards, [EMAIL PROTECTED] COM Sent by: MQSeries To List [email protected] <[EMAIL PROTECTED] cc V.MEDUNIWIEN.AC.A T> Subject Re: Listener; runmqlsr vs amqcrsta within the inetd.conf file 21/07/2005 08:47 Please respond to MQSeries List <[EMAIL PROTECTED] V.MEDUNIWIEN.AC.A T> Obviously Rob has stated that this is possible so is there anyone with any experiences with this config? We have situations in which multiple channels fail when the threaded listener has problems.....never a globally impacting problem when using inetd though......to me, IBM should continue pushimng the inetd as the preferable listener for the UNIX platform........ -------------------------- Sent from my BlackBerry Wireless Handheld ----- Original Message ----- From: KEITH PARMER Sent: 07/20/2005 06:42 PM To: "MQSeries List" <[email protected]> Subject: Re: Listener; runmqlsr vs amqcrsta within the inetd.conf file Question.....is it possible to configure two different ports as listeners, one utilizing inetd and one utilizing the threaded listener? -------------------------- Sent from my BlackBerry Wireless Handheld ----- Original Message ----- From: MQSeries List [EMAIL PROTECTED] Sent: 07/20/2005 06:38 PM To: [email protected] Subject: Re: Listener; runmqlsr vs amqcrsta within the inetd.conf file Yes, the inetd.conf entry must be removed, and inetd must be refreshed. If you try to start runmqlsr without doing this, you'll get a 'port not available' error of some sort. [EMAIL PROTECTED] Sent by: MQSeries List <[email protected]> 07/20/2005 05:30 PM Please respond to MQSeries List <[email protected]> To [email protected] cc Subject Listener; runmqlsr vs amqcrsta within the inetd.conf file I have a quick question. And I don't mean to spawn any preference issues but, we have always configures our AIX boxes to start channels via inetd.conf setting. I believe that that is being replaced as a recommendation to use runmqlsr. A third party vendor is trying to deliver code to us using JBOSS and running into problems. They are asking me to start the listener via runmqlsr. I am willing to try anything but do I need to remove the entry in the inetd.conf file first? I don't have root authority and I will have to get a sys admin to do that which is a longer process. Doug Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html ************************************************************************* PRIVILEGED AND CONFIDENTIAL: This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential and/or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this communication and destroy all copies. ************************************************************************* Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html
