Justin,
I
agree and we do call IBM and we did, unfortunately one problem fixed, 10 lurking
around waiting to pop-up, inetd has proven to be more stable for us. Same goes
for channels (which I consider one of the key things of MQ) problems, why
have things like DISCINT, HBINT or KAINT, when everything works as it is
supposed to?
Michael
-----Original Message-----
From: Justin Fries [mailto:[EMAIL PROTECTED]
Sent: Thursday, July 31, 2003 2:49 PM
To: [EMAIL PROTECTED]
Subject: Re: inet2 vs MQ listener (UNIX) - Answered
Michael,
The listener shouldn't die, period. I don't think MQ should restart dead processes in the way you suggest since that just papers over a larger problem. (One exception is amqzlwa0 which runs the optional custom-written cluster workload exit--because it runs untrusted code, MQ wll restart it if necessary.) If you do see your listener dying, call it in.
Regards,
Justin T. Fries
WebSphere MQ Support
Raleigh, North Carolina
Email: [EMAIL PROTECTED]
[EMAIL PROTECTED]
Sent by: MQSeries List <[EMAIL PROTECTED]>07/31/2003 04:23 AM
Please respond to MQSeries List
To: [EMAIL PROTECTED]
cc:
Subject: Re: inet2 vs MQ listener (UNIX) - Answered
Justin,
thanks for the background!
my biggest concern with listeners has always been that they seem to 'die' at
some point in time... (probably because of all the reasons listed below) and
there is nothing that automatically restarts them, unlike inetd...
Is there something like LISTENER KEEPALIVE(30sec or so...) in the pipeline
(so the MQ checks if the listener is still alive or something.
I know monitoring tools can do this too, but this is one of the basics in MQ
and should be dealt with by the software itself IMHO
Michael
-----Original Message-----
From: Justin Fries [mailto:[EMAIL PROTECTED]
Sent: Wednesday, July 30, 2003 9:38 PM
To: [EMAIL PROTECTED]
Subject: Re: inet2 vs MQ listener (UNIX) - Answered
Hello,
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.
On the other hand, 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 amqcrstas,
forcing administrators to increase maxuproc.
Inetd has no idea when the queue manager is inactive, so it will
start amqcrstas even when the queue manager is shut down. Some people work
around this by disabling the MQ service(s) in inetd; Others simply turn off
the execute bits on amqcrsta to avoid the need for root authority. Anybody
using inetd might take a look at the script
ftp://testcase.boulder.ibm.com/ts/fromibm/mqseries/amqcrsta.ksh (there for a
limited time only) which tries to solve this problem in a slightly more
elegant way.
Despite the limitations of inetd, the fact that it has no limit on
the number of simultaneous connections is crucial. This is the single mark
against runmqlsr, and on very busy systems it is enough to prevent people
from using the listener.
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's 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.
The channel initiator in 5.3 also uses the amqrmppa processes, so it
is now less likely to exhaust its own resources. Since runmqchi never had
to contend with client connections, I think this kind of failure is
relatively unheard of compared to runmqlsr running out of resources.
Cheers,
Justin T. Fries
WebSphere MQ Support
Raleigh, North Carolina
Email: [EMAIL PROTECTED]
Robert Broderick <[EMAIL PROTECTED]>
Sent by: MQSeries List <[EMAIL PROTECTED]>
07/30/2003 02:04 PM
Please respond to MQSeries List
To: [EMAIL PROTECTED]
cc:
Subject: Re: inet2 vs MQ listener (UNIX)
The basics sound the same as it did in 5.2. What I recall is that around 500
and above connections, for some reason, the runmqlsr's knees started to get
wobbely.
I am interested in this as there are discussions going on here to move to
runmqlsr after upgrading to 5.3. I just wanted to know if there was some
factual data behind the recomondation. They were having the QMGR down, bad
app keeps connecting and the strmqm comand cannot catch a breath problem.
just want to make sure that it was a god move except for the fact that IBM
invested some money in desktime to do a little improvement.
bobbee
>From: Tom Schneider <[EMAIL PROTECTED]>
>Reply-To: MQSeries List <[EMAIL PROTECTED]>
>To: [EMAIL PROTECTED]
>Subject: Re: inet2 vs MQ listener (UNIX)
>Date: Wed, 30 Jul 2003 11:53:43 -0400
>
>Bobbee,
>
>The MP61 support pack has a pdf "WebSphere MQ for AIX - Performance
>Evaluations" which has some explanation. It includes a number of
>comparisons of inetd and runmqlsr performance, and compares both methods
>between 5.2 and 5.3 as well. Section 2.2.3 of MP61 contains this text:
>"the 'runmqlsr' has a reduced resource utilisation (one thread per
>connection vs. a process per connection for the 'inetd' listener and a
>smaller memory footprint), so is now the preferred method of running
>client channels and server channels."
>
>-Tom
>
>======================================================
>Tom Schneider / IBM Global Services
>(513) 274-4034
>[EMAIL PROTECTED]
>======================================================
>
>
>
>
>
>Robert Broderick <[EMAIL PROTECTED]>
>Sent by: MQSeries List <[EMAIL PROTECTED]>
>07/30/2003 09:53 AM
>Please respond to MQSeries List
>
>
> To: [EMAIL PROTECTED]
> cc:
> Subject: Re: inet2 vs MQ listener (UNIX)
>
>
>
>It lacks a reasonable explanation as to "Why".
>
> bobbee
>
>
> >From: "Voges, P. (Pieter)" <[EMAIL PROTECTED]>
> >Reply-To: MQSeries List <[EMAIL PROTECTED]>
> >To: [EMAIL PROTECTED]
> >Subject: Re: inet2 vs MQ listener (UNIX)
> >Date: Wed, 30 Jul 2003 15:18:07 +0200
> >
> >http://www.developer.ibm.com/tech/faq/individual/0,,2:28060,00.html
> >
> >Thank you
> >Pieter Voges
> >MQ Support
> >Nedcor Limited
> >Tel: (011) 881 4410
> >Sel: 083 6455 300
> >E-mail: [EMAIL PROTECTED]
> ><http://dotweb.it.nednet.co.za/link.asp?names=Voges,%20Pieter>
> >
> >
> >
> >-----Original Message-----
> >From: Francois Van der Merwe1 [mailto:[EMAIL PROTECTED]
> >Sent: 30 July 2003 01:48
> >To: [EMAIL PROTECTED]
> >Subject: Re: inet2 vs MQ listener (UNIX)
> >
> >
> >Whould you mind pointing me to where I can get this link. Thanks
> >
> >Francois van der Merwe
> >Senior IT Specialist: IBM MQSeries Certified Specialist, Solutions Expert
>&
> >Developer
> >IBM, Cape Town, South Africa
> >+27 (0)82 556 9467 / +27 (0)21 402 5597
> >[EMAIL PROTECTED]
> >
> >
> >
> >
> > "Voges, P.
> > (Pieter)" To:
> >[EMAIL PROTECTED]
> > <[EMAIL PROTECTED] cc:
> > COM> Subject: Re: inet2 vs MQ
> >listener (UNIX)
> > Sent by: MQSeries
> > List
> > <[EMAIL PROTECTED]
> > N.AC.AT>
> >
> >
> > 30/07/2003 12:30
> > Please respond to
> > MQSeries List
> >
> >
> >
> >
> >According to a link from IBM I found on their web page - Inetd is better
> >prior to 5.3 and MQ listener is better from 5.3
> >
> >
> >Thank you
> >Pieter Voges
> >MQ Support
> >Nedcor Limited
> >Tel: (011) 881 4410
> >Sel: 083 6455 300
> >E-mail: [EMAIL PROTECTED]
> ><http://dotweb.it.nednet.co.za/link.asp?names=Voges,%20Pieter>
> >
> >
> >
> >
> >
> >
> >-----Original Message-----
> >From: Francois Van der Merwe1 [mailto:[EMAIL PROTECTED]
> >Sent: 30 July 2003 11:15
> >To: [EMAIL PROTECTED]
> >Subject: inet2 vs MQ listener (UNIX)
> >
> >
> >
> >
> >
> >Is the one better than the other?
> >
> >
> >Francois van der Merwe
> >
> >
> >Instructions for managing your mailing list subscription are provided in
> >the Listserv General Users Guide available at http://www.lsoft.com
> >Archive: http://vm.akh-wien.ac.at/MQSeries.archive
> >
> >
> >
> >
> >
> >This email and any accompanying attachments may contain confidential and
> >proprietary information. This information is private and protected by
>law
> >and, accordingly, if you are not the intended recipient, you are
>requested
> >to delete this entire communication immediately and are notified that any
> >disclosure, copying or distribution of or taking any action based on this
> >information is prohibited.
> >
> >
> >Emails cannot be guaranteed to be secure or free of errors or viruses.
>The
> >sender does not accept any liability or responsibility for any
> >interception, corruption, destruction, loss, late arrival or
>incompleteness
> >of or tampering or interference with any of the information contained in
> >this email or for its incorrect delivery or non-delivery for whatsoever
> >reason or for its effect on any electronic device of the recipient.
> >
> >
> >If verification of this email or any attachment is required, please
>request
> >a hard-copy version.
> >
> >Instructions for managing your mailing list subscription are provided in
> >the Listserv General Users Guide available at http://www.lsoft.com
> >Archive: http://vm.akh-wien.ac.at/MQSeries.archive
> >
> >********************
> >This email and any accompanying attachments may contain confidential and
> >proprietary information. This information is private and protected by
>law
> >and, accordingly, if you are not the intended recipient, you are
>requested
> >to delete this entire communication immediately and are notified that any
> >disclosure, copying or distribution of or taking any action based on this
> >information is prohibited.
> >
> >Emails cannot be guaranteed to be secure or free of errors or viruses.
>The
> >sender does not accept any liability or responsibility for any
> >interception, corruption, destruction, loss, late arrival or
>incompleteness
> >of or tampering or interference with any of the information contained in
> >this email or for its incorrect delivery or non-delivery for whatsoever
> >reason or for its effect on any electronic device of the recipient.
> >
> >If verification of this email or any attachment is required, please
>request
> >a hard-copy version.
> >********************
>
>_________________________________________________________________
>The new MSN 8: smart spam protection and 2 months FREE*
>http://join.msn.com/?page=features/junkmail
>
>Instructions for managing your mailing list subscription are provided in
>the Listserv General Users Guide available at http://www.lsoft.com
>Archive: http://vm.akh-wien.ac.at/MQSeries.archive
>
>Instructions for managing your mailing list subscription are provided in
>the Listserv General Users Guide available at http://www.lsoft.com
>Archive: http://vm.akh-wien.ac.at/MQSeries.archive
_________________________________________________________________
Help STOP SPAM with the new MSN 8 and get 2 months FREE*
http://join.msn.com/?page=features/junkmail
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://vm.akh-wien.ac.at/MQSeries.archive
-----------------------------------------------------------------
ATTENTION:
The information in this electronic mail message is private and
confidential, and only intended for the addressee. Should you
receive this message by mistake, you are hereby notified that
any disclosure, reproduction, distribution or use of this
message is strictly prohibited. Please inform the sender by
reply transmission and delete the message without copying or
opening it.
Messages and attachments are scanned for all viruses known.
If this message contains password-protected attachments, the
files have NOT been scanned for viruses by the ING mail domain.
Always scan attachments before opening them.
-----------------------------------------------------------------
Justin,
thanks for the background!
my biggest concern with listeners has always been that they seem to 'die' at some point in time... (probably because of all the reasons listed below) and there is nothing that automatically restarts them, unlike inetd...
Is there something like LISTENER KEEPALIVE(30sec or so...) in the pipeline (so the MQ checks if the listener is still alive or something.
I know monitoring tools can do this too, but this is one of the basics in MQ and should be dealt with by the software itself IMHO
Michael
-----Original Message-----
From: Justin Fries [mailto:[EMAIL PROTECTED]
Sent: Wednesday, July 30, 2003 9:38 PM
To: [EMAIL PROTECTED]
Subject: Re: inet2 vs MQ listener (UNIX) - Answered
Hello,
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.
On the other hand, 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 amqcrstas, forcing administrators to increase maxuproc.
Inetd has no idea when the queue manager is inactive, so it will start amqcrstas even when the queue manager is shut down. Some people work around this by disabling the MQ service(s) in inetd; Others simply turn off the execute bits on amqcrsta to avoid the need for root authority. Anybody using inetd might take a look at the script ftp://testcase.boulder.ibm.com/ts/fromibm/mqseries/amqcrsta.ksh (there for a limited time only) which tries to solve this problem in a slightly more elegant way.
Despite the limitations of inetd, the fact that it has no limit on the number of simultaneous connections is crucial. This is the single mark against runmqlsr, and on very busy systems it is enough to prevent people from using the listener.
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's 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.
The channel initiator in 5.3 also uses the amqrmppa processes, so it is now less likely to exhaust its own resources. Since runmqchi never had to contend with client connections, I think this kind of failure is relatively unheard of compared to runmqlsr running out of resources.
Cheers,
Justin T. Fries
WebSphere MQ Support
Raleigh, North Carolina
Email: [EMAIL PROTECTED]
Robert Broderick <[EMAIL PROTECTED]>
Sent by: MQSeries List <[EMAIL PROTECTED]>07/30/2003 02:04 PM
Please respond to MQSeries List
To: [EMAIL PROTECTED]
cc:
Subject: Re: inet2 vs MQ listener (UNIX)
The basics sound the same as it did in 5.2. What I recall is that around 500
and above connections, for some reason, the runmqlsr's knees started to get
wobbely.
I am interested in this as there are discussions going on here to move to
runmqlsr after upgrading to 5.3. I just wanted to know if there was some
factual data behind the recomondation. They were having the QMGR down, bad
app keeps connecting and the strmqm comand cannot catch a breath problem.
just want to make sure that it was a god move except for the fact that IBM
invested some money in desktime to do a little improvement.
bobbee
>From: Tom Schneider <[EMAIL PROTECTED]>
>Reply-To: MQSeries List <[EMAIL PROTECTED]>
>To: [EMAIL PROTECTED]
>Subject: Re: inet2 vs MQ listener (UNIX)
>Date: Wed, 30 Jul 2003 11:53:43 -0400
>
>Bobbee,
>
>The MP61 support pack has a pdf "WebSphere MQ for AIX - Performance
>Evaluations" which has some explanation. It includes a number of
>comparisons of inetd and runmqlsr performance, and compares both methods
>between 5.2 and 5.3 as well. Section 2.2.3 of MP61 contains this text:
>"the 'runmqlsr' has a reduced resource utilisation (one thread per
>connection vs. a process per connection for the 'inetd' listener and a
>smaller memory footprint), so is now the preferred method of running
>client channels and server channels."
>
>-Tom
>
>======================================================
>Tom Schneider / IBM Global Services
>(513) 274-4034
>[EMAIL PROTECTED]
>======================================================
>
>
>
>
>
>Robert Broderick <[EMAIL PROTECTED]>
>Sent by: MQSeries List <[EMAIL PROTECTED]>
>07/30/2003 09:53 AM
>Please respond to MQSeries List
>
>
> To: [EMAIL PROTECTED]
> cc:
> Subject: Re: inet2 vs MQ listener (UNIX)
>
>
>
>It lacks a reasonable explanation as to "Why".
>
> bobbee
>
>
> >From: "Voges, P. (Pieter)" <[EMAIL PROTECTED]>
> >Reply-To: MQSeries List <[EMAIL PROTECTED]>
> >To: [EMAIL PROTECTED]
> >Subject: Re: inet2 vs MQ listener (UNIX)
> >Date: Wed, 30 Jul 2003 15:18:07 +0200
> >
> >http://www.developer.ibm.com/tech/faq/individual/0,,2:28060,00.html
> >
> >Thank you
> >Pieter Voges
> >MQ Support
> >Nedcor Limited
> >Tel: (011) 881 4410
> >Sel: 083 6455 300
> >E-mail: [EMAIL PROTECTED]
> ><http://dotweb.it.nednet.co.za/link.asp?names=Voges,%20Pieter>
> >
> >
> >
> >-----Original Message-----
> >From: Francois Van der Merwe1 [mailto:[EMAIL PROTECTED]
> >Sent: 30 July 2003 01:48
> >To: [EMAIL PROTECTED]
> >Subject: Re: inet2 vs MQ listener (UNIX)
> >
> >
> >Whould you mind pointing me to where I can get this link. Thanks
> >
> >Francois van der Merwe
> >Senior IT Specialist: IBM MQSeries Certified Specialist, Solutions Expert
>&
> >Developer
> >IBM, Cape Town, South Africa
> >+27 (0)82 556 9467 / +27 (0)21 402 5597
> >[EMAIL PROTECTED]
> >
> >
> >
> >
> > "Voges, P.
> > (Pieter)" To:
> >[EMAIL PROTECTED]
> > <[EMAIL PROTECTED] cc:
> > COM> Subject: Re: inet2 vs MQ
> >listener (UNIX)
> > Sent by: MQSeries
> > List
> > <[EMAIL PROTECTED]
> > N.AC.AT>
> >
> >
> > 30/07/2003 12:30
> > Please respond to
> > MQSeries List
> >
> >
> >
> >
> >According to a link from IBM I found on their web page - Inetd is better
> >prior to 5.3 and MQ listener is better from 5.3
> >
> >
> >Thank you
> >Pieter Voges
> >MQ Support
> >Nedcor Limited
> >Tel: (011) 881 4410
> >Sel: 083 6455 300
> >E-mail: [EMAIL PROTECTED]
> ><http://dotweb.it.nednet.co.za/link.asp?names=Voges,%20Pieter>
> >
> >
> >
> >
> >
> >
> >-----Original Message-----
> >From: Francois Van der Merwe1 [mailto:[EMAIL PROTECTED]
> >Sent: 30 July 2003 11:15
> >To: [EMAIL PROTECTED]
> >Subject: inet2 vs MQ listener (UNIX)
> >
> >
> >
> >
> >
> >Is the one better than the other?
> >
> >
> >Francois van der Merwe
> >
> >
> >Instructions for managing your mailing list subscription are provided in
> >the Listserv General Users Guide available at http://www.lsoft.com
> >Archive: http://vm.akh-wien.ac.at/MQSeries.archive
> >
> >
> >
> >
> >
> >This email and any accompanying attachments may contain confidential and
> >proprietary information. This information is private and protected by
>law
> >and, accordingly, if you are not the intended recipient, you are
>requested
> >to delete this entire communication immediately and are notified that any
> >disclosure, copying or distribution of or taking any action based on this
> >information is prohibited.
> >
> >
> >Emails cannot be guaranteed to be secure or free of errors or viruses.
>The
> >sender does not accept any liability or responsibility for any
> >interception, corruption, destruction, loss, late arrival or
>incompleteness
> >of or tampering or interference with any of the information contained in
> >this email or for its incorrect delivery or non-delivery for whatsoever
> >reason or for its effect on any electronic device of the recipient.
> >
> >
> >If verification of this email or any attachment is required, please
>request
> >a hard-copy version.
> >
> >Instructions for managing your mailing list subscription are provided in
> >the Listserv General Users Guide available at http://www.lsoft.com
> >Archive: http://vm.akh-wien.ac.at/MQSeries.archive
> >
> >********************
> >This email and any accompanying attachments may contain confidential and
> >proprietary information. This information is private and protected by
>law
> >and, accordingly, if you are not the intended recipient, you are
>requested
> >to delete this entire communication immediately and are notified that any
> >disclosure, copying or distribution of or taking any action based on this
> >information is prohibited.
> >
> >Emails cannot be guaranteed to be secure or free of errors or viruses.
>The
> >sender does not accept any liability or responsibility for any
> >interception, corruption, destruction, loss, late arrival or
>incompleteness
> >of or tampering or interference with any of the information contained in
> >this email or for its incorrect delivery or non-delivery for whatsoever
> >reason or for its effect on any electronic device of the recipient.
> >
> >If verification of this email or any attachment is required, please
>request
> >a hard-copy version.
> >********************
>
>_________________________________________________________________
>The new MSN 8: smart spam protection and 2 months FREE*
>http://join.msn.com/?page=features/junkmail
>
>Instructions for managing your mailing list subscription are provided in
>the Listserv General Users Guide available at http://www.lsoft.com
>Archive: http://vm.akh-wien.ac.at/MQSeries.archive
>
>Instructions for managing your mailing list subscription are provided in
>the Listserv General Users Guide available at http://www.lsoft.com
>Archive: http://vm.akh-wien.ac.at/MQSeries.archive
_________________________________________________________________
Help STOP SPAM with the new MSN 8 and get 2 months FREE*
http://join.msn.com/?page=features/junkmail
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://vm.akh-wien.ac.at/MQSeries.archive
-----------------------------------------------------------------
ATTENTION:
The information in this electronic mail message is private and
confidential, and only intended for the addressee. Should you
receive this message by mistake, you are hereby notified that
any disclosure, reproduction, distribution or use of this
message is strictly prohibited. Please inform the sender by
reply transmission and delete the message without copying or
opening it.
Messages and attachments are scanned for all viruses known.
If this message contains password-protected attachments, the
files have NOT been scanned for viruses by the ING mail domain.
Always scan attachments before opening them.
-----------------------------------------------------------------
