| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| MQ Listeners inAIX |
« View previous topic :: View next topic » |
| Author |
Message
|
| venkataramanan |
 Posted: Thu May 19, 2005 10:14 pm Post subject: MQ Listeners inAIX |
 |
|
Apprentice
Joined: 18 Sep 2002
Posts: 47
Location: Chennai, India
|
Hi,
What is the general concept to create a Listener Port on unix AIX? How do you create and what is the procedure or command?
Regards
venkat |
|
| Back to top |
|
 |
| fschofer |
| Posted: Fri May 20, 2005 12:10 am Post subject: |
|
|
Knight
Joined: 02 Jul 2001
Posts: 524
Location: Mainz, Germany
|
Hi,
take a look at the Websphere MQ Intercommunication Guide.
=>
Chapter 14. Example configuration - IBM WebSphere MQ for
AIX
Greetings
Frank |
|
| Back to top |
|
|
| bower5932 |
| Posted: Fri May 20, 2005 6:33 am Post subject: |
|
|
Jedi Knight
Joined: 27 Aug 2001
Posts: 3023
Location: Dallas, TX, USA
|
| I believe the Intercommunication manual takes a inetd view of life. You might also want to consider using the runmqlsr command to start your different listener ports. You should be able to search on this site to find information on the pros and cons of each method. |
|
| Back to top |
|
|
| xxx |
| Posted: Fri May 20, 2005 6:42 am Post subject: |
|
|
Centurion
Joined: 13 Oct 2003
Posts: 137
|
with the reboots and other issues I believe it is better to stick with inetd,
we have one thing less to deal with if the port is setup with the help of inetd,
I read that when we start with runmqlsr with new connections they are all threads and not seperate process , but I did not find any performance issue in general using the inetd ,
Please correct me if there is any good reason why we have to start with runmqlsr |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Fri May 20, 2005 6:47 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
Runmqlsr is significantly better than inetd, performance wise, in terms of process usage and memory/cpu overhead. Just because you haven't seen performance lags doesn't mean they aren't there.
It is also the current IBM recommendation, and signficantly more likely to be supported long term.
And enabling runmqlsr is not really any harder than enabling inetd. You edit your startup configuration to run a script that starts listeners.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Fri May 20, 2005 7:33 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| xxx wrote: |
| Please correct me if there is any good reason why we have to start with runmqlsr |
| Quote: |
In MQSeries 5.2 and previous releases, runmqlsr ran each inbound connection as a new thread within itself. If runmqlsr ran out of resources (memory, threads, file descriptors), then it would not accept any new connections. This massively threaded approach worked well on systems with a limited number of channels, but on very busy systems it was necessary to set up multiple listeners and balance connections across them.
The inetd daemon starts a new amqcrsta process for each inbound connection. There is no chance an amqcrsta responsible for only one channel will run out of resources, so even the busiest of queue managers requires only a single port in inetd. However, this massively unthreaded approach means that busy systems may have hundreds of amqcrsta processess, forcing administrators to increase maxuproc. Inetd has no idea when the queue manager is inactive, so it will start amqcrsta processes even when the queue manager is shut down.
WebSphere MQ 5.3 removes the listener scalability problem once and for all. Rather than running each inbound connection as a thread within itself, runmqlsr now passes connections to one of the amqrmppa channel pooling processes. These amqrmppa's are threaded, but not massively so. This means they do not exhaust per-process resources or force administrators to increase maxuproc. The listener will start new amqrmppa processes as needed, so a single listener can now handle an unbounded number of connections. The listener is aware of the queue manager's status at all times, so it is also very quick to deny connections when the queue manager is down.
|
http://www.developer.ibm.com/tech/faq/results/0,1322,1%253A401%253A416%253A148%253AGeneral,00.html#q148
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
|
|
|
| |
|
Page 1 of 1 |
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
|
|
