ASG
IBM
Zystems
Cressida
Icon
Netflexity
 
  MQSeries.net
Search  Search       Tech Exchange      Education      Certifications      Library      Info Center      SupportPacs      LinkedIn  Search  Search                                                                   FAQ  FAQ   Usergroups  Usergroups
 
Register  ::  Log in Log in to check your private messages
 
RSS Feed - WebSphere MQ Support RSS Feed - Message Broker Support

MQSeries.net Forum Index » IBM MQ Installation/Configuration Support » Multiple listeners on a queue manager?

Post new topic  Reply to topic
 Multiple listeners on a queue manager? « View previous topic :: View next topic » 
Author Message
zpat
PostPosted: Tue Apr 14, 2009 6:33 am    Post subject: Multiple listeners on a queue manager? Reply with quote

Jedi Council

Joined: 19 May 2001
Posts: 5866
Location: UK

What are the advantages of running more than one listener on a queue manager?

For example would it be helpful to separate client channel applications (which might generate too many connections) from admin access with M071 or MQ explorer?

The following extract from an IBM presentation suggests there is a benefit but I think maxchannels being reached would stop any new connections regardless of the listener being used?

Quote:
Most client applications include code to rebuild a connection that is severed. If the reconnect
attempts are not throttled down, the QMgr can become flooded with connection attempts. While
this does not provide an avenue for gaining administrative access, it does make for an effective
denial of service attack. It is often advisable to run separate listeners for administrative and
routine application traffic. In the event of a runaway client application, it’s listener can be stopped
without losing administrative connectivity and thus restoring service to the queue manager.


What I think this is saying is that restarting the one listener would release the channels acquired through it without affecting the other channels?
Back to top
View user's profile Send private message
exerk
PostPosted: Tue Apr 14, 2009 6:45 am    Post subject: Reply with quote

Jedi Council

Joined: 02 Nov 2006
Posts: 6339

That's how I read it. On the other hand, with the channel throttling available in V7.0, some may consider separation as redundant. My personal view is that I prefer 'Admin' channels to have their own listener.
_________________
It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys.
Back to top
View user's profile Send private message
PeterPotkay
PostPosted: Tue Apr 14, 2009 8:45 am    Post subject: Re: Multiple listeners on a queue manager? Reply with quote

Poobah

Joined: 15 May 2001
Posts: 7722

zpat wrote:
What I think this is saying is that restarting the one listener would release the channels acquired through it without affecting the other channels?


Not quite. runmqlsr listens for new connections, then hands them off to amqrmppa. If you stop a Listner, it has no impact on channels already running, but new incoming connections obviously will fail.

The quote is saying you can stop LISTNER.APPS (port 1414), preventing new channels from starting, but still be able to admin the QM remotely via LISTNER.MQADMIN, say port 1415.

I set up a dedicated Listener for each of my partner companies. A Denial of Service attack, either intentional or not, allows be to shutdown one company without impacting the others.
_________________
Peter Potkay
Keep Calm and MQ On
Back to top
View user's profile Send private message
Sam Uppu
PostPosted: Tue Apr 14, 2009 1:46 pm    Post subject: Reply with quote

Yatiri

Joined: 11 Nov 2008
Posts: 610

Is there any real advantage of using a seperate listener on a single QMgr for each application when multiple apps share/use the same QMgr?. Would appreciate if there is any link.

Thanks.
Back to top
View user's profile Send private message
mqjeff
PostPosted: Tue Apr 14, 2009 3:53 pm    Post subject: Reply with quote

Grand Master

Joined: 25 Jun 2008
Posts: 17447

Sam Uppu wrote:
Is there any real advantage of using a seperate listener on a single QMgr for each application when multiple apps share/use the same QMgr?. Would appreciate if there is any link.


It depends on how often the applications connect, and how they connect.
Back to top
View user's profile Send private message
gbaddeley
PostPosted: Tue Apr 14, 2009 5:30 pm    Post subject: Reply with quote

Jedi Knight

Joined: 25 Mar 2003
Posts: 2538
Location: Melbourne, Australia

Sam Uppu wrote:
Is there any real advantage of using a seperate listener on a single QMgr for each application when multiple apps share/use the same QMgr?


Not really, this capability is rarely used. I have only ever seen it used by one application, so that they could control who and when channels could be run into their qmgr, by starting and stopping multiple listeners using cron.
_________________
Glenn
Back to top
View user's profile Send private message
sumit
PostPosted: Wed Apr 15, 2009 4:21 am    Post subject: Re: Multiple listeners on a queue manager? Reply with quote

Partisan

Joined: 19 Jan 2006
Posts: 398

PeterPotkay wrote:
runmqlsr listens for new connections, then hands them off to amqrmppa. If you stop a Listner, it has no impact on channels already running, but new incoming connections obviously will fail.


Great piece of info. Thnx
_________________
Regards
Sumit
Back to top
View user's profile Send private message Yahoo Messenger
zpat
PostPosted: Wed Apr 15, 2009 6:48 am    Post subject: Reply with quote

Jedi Council

Joined: 19 May 2001
Posts: 5866
Location: UK

OK, so the main benefit (for an internal QM) would perhaps be to allow Admin access whilst keeping MQ clients or other QMs from connecting until you are ready for them.

Could also be useful in hot DR scenarios where the DR QM is ready but not connected.
Back to top
View user's profile Send private message
Rahul999
PostPosted: Mon May 11, 2009 7:00 pm    Post subject: Reply with quote

Centurion

Joined: 14 Mar 2007
Posts: 134

Hi all,

What would be the impact of having multiple listener running on the same port. I got a queue manager where the are a total of 5 listeners(belonging to the same queue manager) running on same port. my understanding was if already a listener is running on a given port then you can not have another listener on the same port.

Quote:

mqm 11393 11376 0 Apr23 ? 00:00:01 /opt/mqm/bin/runmqlsr -r -m xxxxxxx -t TCP -p 1418
mqm 11401 11393 0 Apr23 ? 00:00:00 /opt/mqm/bin/runmqlsr -r -m xxxxxxx -t TCP -p 1418
mqm 11402 11401 0 Apr23 ? 00:00:00 /opt/mqm/bin/runmqlsr -r -m xxxxxxx -t TCP -p 1418
mqm 11403 11401 0 Apr23 ? 00:00:00 /opt/mqm/bin/runmqlsr -r -m xxxxxxx -t TCP -p 1418
mqm 11409 11401 0 Apr23 ? 00:00:00 /opt/mqm/bin/runmqlsr -r -m xxxxxxx -t TCP -p 1418


if you see above there are a total of 5 instances of same listener is running on the same queue manager and same port. What can be the cause of this problem?

Here the server/MQ version details -
Quote:

O/S - Linux
Name: WebSphere MQ
Version: 6.0.0.0
CMVC level: p000-L050519
BuildType: IKAP - (Production)


If you see there is no CSD for MQ is installed, could it be the root cause of this problem?
Back to top
View user's profile Send private message Send e-mail Visit poster's website
harish_td
PostPosted: Mon May 11, 2009 7:13 pm    Post subject: Reply with quote

Master

Joined: 13 Feb 2006
Posts: 236

This is how Linux displays the MQ Listener process tree. If you notice carefully they are spawned out of the same OS process. They are not multiple listeners but a single listener on a single resource.

Quote:

mqm 11393 11376 0 Apr23 ? 00:00:01 /opt/mqm/bin/runmqlsr -r -m xxxxxxx -t TCP -p 1418
mqm 11401 11393 0 Apr23 ? 00:00:00 /opt/mqm/bin/runmqlsr -r -m xxxxxxx -t TCP -p 1418
mqm 11402 11401 0 Apr23 ? 00:00:00 /opt/mqm/bin/runmqlsr -r -m xxxxxxx -t TCP -p 1418
mqm 11403 11401 0 Apr23 ? 00:00:00 /opt/mqm/bin/runmqlsr -r -m xxxxxxx -t TCP -p 1418
mqm 11409 11401 0 Apr23 ? 00:00:00 /opt/mqm/bin/runmqlsr -r -m xxxxxxx -t TCP -p 1418
Back to top
View user's profile Send private message Yahoo Messenger
matkalouie
PostPosted: Mon Apr 04, 2011 11:55 pm    Post subject: Reply with quote

Newbie

Joined: 29 Nov 2010
Posts: 8

Sorry to bump this old thread but i am similar behavior as above :

mqm 5610 4598 0 00:29 ? 00:00:00 /opt/mqm/bin/runmqlsr -r -m IMDALAPP200.LXS1 -t TCP -p 1414
mqm 5619 5610 0 00:29 ? 00:00:00 /opt/mqm/bin/runmqlsr -r -m IMDALAPP200.LXS1 -t TCP -p 1414
mqm 5620 5619 0 00:29 ? 00:00:00 /opt/mqm/bin/runmqlsr -r -m IMDALAPP200.LXS1 -t TCP -p 1414
mqm 5622 5619 0 00:29 ? 00:00:00 /opt/mqm/bin/runmqlsr -r -m IMDALAPP200.LXS1 -t TCP -p 1414
mqm 5627 5619 0 00:29 ? 00:00:00 /opt/mqm/bin/runmqlsr -r -m IMDALAPP200.LXS1 -t TCP -p 1414


My QManager has a single listener and two receiver channels running on it.

Off late i see a number of MQM Process being created.

Can somebody help me understand why multiple processes are being made ?

Name: WebSphere MQ
Version: 6.0.0.0
CMVC level: p000-L050519
BuildType: IKAP - (Production)
OS - Linux

Thanks
Back to top
View user's profile Send private message
gbaddeley
PostPosted: Tue Apr 05, 2011 3:49 pm    Post subject: Reply with quote

Jedi Knight

Joined: 25 Mar 2003
Posts: 2538
Location: Melbourne, Australia

matkalouie wrote:
Sorry to bump this old thread but i am similar behavior as above


Did you not read the post of Mon May 11, 2009 5:13 pm ? Its just the way ps displays the process tree on Linux. There is only one listener on 1414.
_________________
Glenn
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic  Reply to topic Page 1 of 1

MQSeries.net Forum Index » IBM MQ Installation/Configuration Support » Multiple listeners on a queue manager?
Jump to:  



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
Protected by Anti-Spam ACP
 
 


Theme by Dustin Baccetti
Powered by phpBB © 2001, 2002 phpBB Group

Copyright © MQSeries.net. All rights reserved.