Re: inet2 vs MQ listener (UNIX) - Answered
Justin, I tried to look at the script on the testcase sight, but it is no longer there. Is there somewhere I can get a copy of it? Thanks, Jim Justin Fries To: [EMAIL PROTECTED] [EMAIL PROTECTED] cc: Sent by: MQSeries List Subject: Re: inet2 vs MQ listener (UNIX) - Answered [EMAIL PROTECTED] 07/30/2003 02:37 PM Please respond to MQSeries List 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] To: Sent by: MQSeries List [EMAIL PROTECTED] [EMAIL PROTECTED] cc: Subject:Re: inet2 vs MQ listener (UNIX) 07/30/2003 02:04 PM Please respond to MQSeries List 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
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
PMTo: [EMAIL PROTECTED]Subject: Re: inet2 vs MQ
listener (UNIX) - AnsweredHello,
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 500and above
connections, for some reason, the runmqlsr's knees started to
getwobbely.I am interested in this as there are discussions going
on here to move torunmqlsr after upgrading to 5.3. I just wanted to know
if there was somefactual data behind the recomondation. They were having
the QMGR down, badapp 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 IBMinvested some money in desktime to do a little
improvement.bobbeeFrom: 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
-0400Bobbee,The MP61 support pack has a pdf
"WebSphere MQ for AIX - PerformanceEvaluations" which has some
explanation. It includes a number ofcomparisons of inetd
and runmqlsr performance, and compares both methodsbetween 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
perconnection vs. a process per connection f
Re: inet2 vs MQ listener (UNIX) - Answered
What is needed is an automation package that can monitor the listener, and a package to monitor the monitor, and then a person to watch a screen to call the help desk when the monitor's monitor stops, and a backup for that person. Who said computers weren't labor intensive? IBM's original intention with MQ (before WMQ) was to create a robust framework with sufficient interfaces for Third Party Vendors, not to be confused with Third World Vendors, to provide the bells and whistles. Has that philosophy changed? [EMAIL PROTECTED] NK.COM To: [EMAIL PROTECTED] Sent by: cc: MQSeries List Subject: Re: inet2 vs MQ listener (UNIX) - Answered [EMAIL PROTECTED] n.AC.AT 07/31/2003 04:23 AM Please respond to MQSeries List 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] To: Sent by: MQSeries List [EMAIL PROTECTED] [EMAIL PROTECTED] cc: Subject:Re
Re: inet2 vs MQ listener (UNIX)
Thank, As soon as the 13 managers I report to here go on vacation, or take a stree related holiday at the hospital I will read it. Actually, as soon as I deplete my inbox here I will download it and place it high in my to Do list. Thanks a lot for your input. It is much appreciated!! 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 14:57:43 -0400 Bobbee, I believe the issue with runmqlsr breaking around 500 connections was resolved in 5.3, and that this is why the recommendation about which listener to use has changed for 5.3. The MP61.pdf has quite a bit more in it about the Inetd vs. runmqlsr question than what I pasted into the previous note. -Tom == Tom Schneider / IBM Global Services (513) 274-4034 [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
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
Re: inet2 vs MQ listener (UNIX) - Answered
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 oneof 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 PMTo: [EMAIL PROTECTED]Subject: Re: inet2 vs MQ listener (UNIX) - AnsweredMichael, 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) - AnsweredJustin,thanks for the background!my biggest concern with listeners has always been that they seem to 'die' atsome point in time... (probably because of all the reasons listed below) andthere 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 MQand should be dealt with by the software itself IMHOMichael-Original Message-From: Justin Fries [mailto:[EMAIL PROTECTED]Sent: Wednesday, July 30, 2003 9:38 PMTo: [EMAIL PROTECTED]Subject: Re: inet2 vs MQ listener (UNIX) - AnsweredHello, In MQSeries 5.2 and previous releases, runmqlsr ran each inboundconnection as a new thread within itself. If runmqlsr ran out ofresources--memory, threads, file descriptors--then it would not accept anynew connections. This "massively threaded" approach worked well on systemswith a limited number of channels, but on very busy systems it was necessaryto set up multiple listeners and balance connections across them. On the other hand, the inetd daemon starts a new amqcrsta processfor each inbound connection. There is no chance an amqcrsta responsible foronly one channel will run out of resources, so even the busiest of queuemanagers requires only a single port in inetd. However, this "massivelyunthreaded" 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 willstart amqcrstas even when the queue manager is shut down. Some people workaround this by disabling the MQ service(s) in inetd; Others simply turn offthe execute bits on amqcrsta to avoid the need for root authority. Anybodyusing inetd might take a look at the scriptftp://testcase.boulder.ibm.com/ts/fromibm/mqseries/amqcrsta.ksh (there for alimited time only) which tries to solve this problem in a slightly moreelegant way. Despite the limitations of inetd, the fact that it has no limit onthe number of simultaneous connections is crucial. This is the single markagainst runmqlsr, and on very busy systems it is enough to prevent peoplefrom using the listener. WebSphere MQ 5.3 removes the listener scalability problem once andfor all. Rather than running each inbound connection as a thread withinitself, runmqlsr now passes connections to one of the amqrmppa "channelpooling" processes. These amqrmppa's are threaded, but not massively so;This means they do not exhaust per-process resources or force administratorsto increase maxuproc. The listener will start new amqrmppa's as needed, soa single listener can now handle an unbounded number of connections. Thelistener is aware of the queue manager's status at all times, so it is alsovery quick to deny connections when the queue manager is down. The channel initiator in 5.3 also uses the amqrmppa processes, so itis now less likely to exhaust its own resources. Since runmqchi never hadto contend with client connections, I think this kind of failure isrelatively 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 PMPlease respond to MQSeries List To: [EMAIL PROTECTED] cc: Subject: Re: inet2 vs MQ listener (UNIX)The basics sound the s
Re: inet2 vs MQ listener (UNIX) - Answered
Michael, Channel parameters like DISCINT, HBINT, KAINT, etc. are intended to work around problems with networks, which will always be with us (unless someone invents a perfect network that never fails--if so, let me in on your IPO). If you're running MQ 5.2, you should find the 5.3 listener more stable since it has much less work to do--just listen() on a socket, accept() a connection, and give it to amqrmppa to handle. Which version of MQ are you running? You can set up runmqlsr to run out of inittab with the 'respawn' option. This would restart it in the way you desire (although I would still call service if you find it terminating for any reason). Just edit /etc/inittab and run 'telinit q' to force init to reread the file. One downside is that you will need root authority to stop the listener, unless you just turn off its execute bits (although I'm not sure how init will react to that). Cheers, Justin T. Fries WebSphere MQ Support Raleigh, North Carolina Email: [EMAIL PROTECTED] [EMAIL PROTECTED] Sent by: MQSeries List [EMAIL PROTECTED] 07/31/2003 09:23 AM Please respond to MQSeries List To: [EMAIL PROTECTED] cc: Subject: Re: inet2 vs MQ listener (UNIX) - Answered 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]
Re: inet2 vs MQ listener (UNIX) - Answered
Does anyone have the EMAIL with the boulder link for the INETD amqcrsta alternate approach. I mistakenly deleted it befor capturing it. Could you repost it. thnaks bobbee From: [EMAIL PROTECTED] Reply-To: MQSeries List [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: inet2 vs MQ listener (UNIX) - Answered Date: Thu, 31 Jul 2003 15:23:53 +0200 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
Re: inet2 vs MQ listener (UNIX) - Answered
For B
oh double-b egh...
-Original Message-From: Justin Fries
[mailto:[EMAIL PROTECTED]Sent: Wednesday, July 30, 2003 3:38
PMTo: [EMAIL PROTECTED]Subject: Re: inet2 vs MQ
listener (UNIX) - AnsweredHello,
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 500and above
connections, for some reason, the runmqlsr's knees started to
getwobbely.I am interested in this as there are discussions going
on here to move torunmqlsr after upgrading to 5.3. I just wanted to know
if there was somefactual data behind the recomondation. They were having
the QMGR down, badapp 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 IBMinvested some money in desktime to do a little
improvement.bobbeeFrom: 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
-0400Bobbee,The MP61 support pack has a pdf
"WebSphere MQ for AIX - PerformanceEvaluations" which has some
explanation. It includes a number ofcomparisons of inetd
and runmqlsr performance, and compares both methodsbetween 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
perconnection vs. a process per connection for the 'inetd' listener
and asmaller memory footprint), so is now the preferred method of
runningclient 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 AMPlease
respond to MQSeries List
To: [EMAIL PROTECTED]
cc: Sub
Re: inet2 vs MQ listener (UNIX) - Answered
ftp://testcase.boulder.ibm.com/ts/fromibm/mqseries/amqcrsta.ksh -Original Message- From: Robert Broderick [mailto:[EMAIL PROTECTED] Sent: Thursday, July 31, 2003 11:36 AM To: [EMAIL PROTECTED] Subject: Re: inet2 vs MQ listener (UNIX) - Answered Does anyone have the EMAIL with the boulder link for the INETD amqcrsta alternate approach. I mistakenly deleted it befor capturing it. Could you repost it. thnaks bobbee From: [EMAIL PROTECTED] Reply-To: MQSeries List [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: inet2 vs MQ listener (UNIX) - Answered Date: Thu, 31 Jul 2003 15:23:53 +0200 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
Re: inet2 vs MQ listener (UNIX) - Answered
Justin:
Nice
input... However, has there been any thought to using both inetd and
runmqlsr.Maybe keep the inetd for channels between QMgrs and
runmqlsr for client connections. I liked an earlier comment by
"separating your eggs from 1 basket".
There
was once a support pack -- I've lost the reference andbelieve IBM has
pulled it -- using the AgentClassMap and AgentClassLimitTuningParameter
stanza parameters that addressedseparation of
connections.
-B
Brian Bumpass
Wachovia
Bank Enterprise Infrastructure [EMAIL PROTECTED] Phone - (704) 590-5620
Pager - (800)
425-2613
-Original Message-From: Justin Fries
[mailto:[EMAIL PROTECTED]Sent: Wednesday, July 30, 2003 3:38
PMTo: [EMAIL PROTECTED]Subject: Re: inet2 vs MQ
listener (UNIX) - AnsweredHello,
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 500and above
connections, for some reason, the runmqlsr's knees started to
getwobbely.I am interested in this as there are discussions going
on here to move torunmqlsr after upgrading to 5.3. I just wanted to know
if there was somefactual data behind the recomondation. They were having
the QMGR down, badapp 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 IBMinvested some money in desktime to do a little
improvement.bobbeeFrom: 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
-0400Bobbee,The MP61 support pack has a pdf
"WebSphere MQ for AIX - PerformanceEvaluations" which has some
explanation. It includes a number ofcomparisons of inetd
and runmqlsr performance, and compares both methodsbetween 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
pe
Re: inet2 vs MQ listener (UNIX) - Answered
OK this is s.h.i.t-4.brains bobbee. I had that EMAIL. Like ALL good EMAILs I save them to a document called MQSERIES_Discussions.doc. This document has gotten me outta a lot of problems. As I said I save it and scanned it quickly and didn't see that info. So I greatly appreciate the reply. Which made me reflect on the brain matter composition! bobbee From: Wyatt, T. Rob [EMAIL PROTECTED] Reply-To: MQSeries List [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: inet2 vs MQ listener (UNIX) - Answered Date: Thu, 31 Jul 2003 08:50:19 -0700 For B oh double-b egh... -Original Message- From: Justin Fries [mailto:[EMAIL PROTECTED] Sent: Wednesday, July 30, 2003 3: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
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
Re: inet2 vs MQ listener (UNIX)
Title: RE: inet2 vs MQ listener (UNIX) 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.
Re: inet2 vs MQ listener (UNIX)
Is it really betteror did it just cach up. runmqlsr does help in a situation where you have an overzelous programmer who ABSOLUTLY MUST get a connection to the QMGR where they send their process into an endless loop trying to connect. The INETD version keep spawning amqcrsta's and you have a problem restarting the QMGR. If you have ever been in this situation it is enough to make you switch once at 5.3. Other than that, form explanation on the LIST it's a call between threads and processes which I tink comes down to resources. 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 12:30:44 +0200 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. _ Tired of spam? Get advanced junk mail protection with MSN 8. 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
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
Re: inet2 vs MQ listener (UNIX)
Title: RE: inet2 vs MQ listener (UNIX) 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.
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
AW: Re: inet2 vs MQ listener (UNIX)
I assume that the answer will quickly be found with one of the mentioned tools from www.sysinternals.com. Other than that - there are no 'build in tools' in W2K (as well as in any other Win-OS) to figure out the Why. Enrico -Ursprüngliche Nachricht- Von: Robert Broderick [mailto:[EMAIL PROTECTED] Gesendet: Mittwoch, 30. Juli 2003 15:53 An: [EMAIL PROTECTED] Betreff: 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
Re: inet2 vs MQ listener (UNIX)
Title: RE: inet2 vs MQ listener (UNIX) is there a clear reason for this argument? Is it really a recommentation from IBM? Benjamin Zhou State Street Corp. -Original Message-From: Voges, P. (Pieter) [mailto:[EMAIL PROTECTED]Sent: Wednesday, July 30, 2003 9:18 AMTo: [EMAIL PROTECTED]Subject: Re: inet2 vs MQ listener (UNIX) 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.
Re: inet2 vs MQ listener (UNIX)
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
Re: inet2 vs MQ listener (UNIX)
Does anyone out their have any recent experience of Websphere Business Integration - Specifically Crossworlds. I urgently need some help in this area Thanks Paul -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] On Behalf Of Tom Schneider Sent: 30 July 2003 16:54 To: [EMAIL PROTECTED] Subject: Re: inet2 vs MQ listener (UNIX) 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
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
Re: inet2 vs MQ listener (UNIX)
Bobbee, I believe the issue with runmqlsr breaking around 500 connections was resolved in 5.3, and that this is why the recommendation about which listener to use has changed for 5.3. The MP61.pdf has quite a bit more in it about the Inetd vs. runmqlsr question than what I pasted into the previous note. -Tom == Tom Schneider / IBM Global Services (513) 274-4034 [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
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
Re: inet2 vs MQ listener (UNIX)
I think one reasonable explanation as to why is that you cannot make use of the new channel pooling feature introduced with runmqlsr in 5.3, which dramatically increases the number of clients you can connect to a box. Can't use that with inetd, which spawns a new amqcrsta for every incoming open request, since it doesn't know [EMAIL PROTECTED] about whether it's MQ or something else calling... ;-) Resource usage greatly improves (ie. decreases) with channel pooling. There might be other reasons, too. my $0.0001, Stefan From: Robert Broderick [EMAIL PROTECTED] Reply-To: MQSeries List [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: inet2 vs MQ listener (UNIX) Date: Wed, 30 Jul 2003 09:53:11 -0400 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
