| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| Usage for multiple listeners and runmqlsr |
« View previous topic :: View next topic » |
| Author |
Message
|
| hdomin257 |
 Posted: Mon Oct 25, 2021 10:52 am Post subject: Usage for multiple listeners and runmqlsr |
 |
|
Newbie
Joined: 27 Nov 2020
Posts: 7
|
Hi folks,
I'm learning from IBM training materials and I bumped to listeners. resp runmqlsr command.
I know that we can have a default listener on 1414 for QM. Also, I know that we can create a listener - DEFINE LISTENER...
But, what is the usage for runmqlsr command? Is it for listeners we create with CONTROL(MANUAL)?
For example when we create multiple listeners for different transport types or ports?
What is the usage for multiple listeners? I found this topic, but it seems like a not very usual case:
http://mqseries.net/phpBB/viewtopic.php?t=22055&postdays=0&postorder=asc&start=15&sid=b82c04230b76c943bd6b6d6c5ff988f4
TLDR: security from dos attacks - when 1 listener shut down, it doesn't stop the whole QM - possibility to "unofficially" shut only 1 listener.
sorry if it is a silly question, but there is a lot of technical information without examples for us beginners.
thx |
|
| Back to top |
|
 |
| bruce2359 |
| Posted: Mon Oct 25, 2021 12:00 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9396
Location: US: west coast, almost. Otherwise, enroute.
|
Runmqlsr is an MQ control program that listens for inbound network flows, passing the flow to the qmgr. The same program is launched when the LISTENER object is defined and started.
The ‘well known’ port is 1414, but you can use any of the 64K port numbers. 1414 is the default if not explicitly specified.
Yes, you can have multiple listeners for a qmgr - each listening on a different port number.
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live.
Last edited by bruce2359 on Mon Oct 25, 2021 4:19 pm; edited 1 time in total |
|
| Back to top |
|
|
| gbaddeley |
| Posted: Mon Oct 25, 2021 4:14 pm Post subject: |
|
|
Jedi
Joined: 25 Mar 2003
Posts: 2494
Location: Melbourne, Australia
|
runmqlsr exists from early versions of MQ. The LISTENER object was later added so that the qmgr could control one or more port listeners (runmqlsr processes) as part of its start up / shutdown, and for manual control of runmqlsr using START LISTENER and STOP LISTENER mqsc's. Very nice when it was introduced.
A qmgr can have multiple listener ports to allow for separation of usage by incoming channels. This could be for functional reasons, eg. having MQ admin or other app SVRCONNs on a separate port, or to allow specific set up of firewall rules to control access from other servers or network segments, and the ability to switch the port listeners on and off from within MQ.
_________________
Glenn |
|
| Back to top |
|
|
| hughson |
| Posted: Mon Oct 25, 2021 9:33 pm Post subject: |
|
|
Padawan
Joined: 09 May 2013
Posts: 1914
Location: Bay of Plenty, New Zealand
|
There are two models for running a MQ listener. They have different pros and cons, and both use the same code (that is the runmqlsr executable) at the core. You can see this if you take a look at the processes running on your machine.
- Create a listener object and have the queue manager start it for you (or manually start and stop as required). This can have an advantage that once defined, you can essentially forget about it. If your queue manager is running, so is your listener, but if not it is not. The downside of this is that when your queue manager is not running, neither is the listener and so any TCP/IP connections that attempt to be made to your listener are told "host unreachable" or some such, and you cannot be sure whether than means the queue manager is not running, or whether you typed in the CONNAME wrong.
- Use the runmqlsr command directly. This has the advantage that even when the queue manager is not running, the runmqlsr process can continue to run. This means that a TCP/IP connection such as a client application can be given a more useful return code saying that the queue manager is not currently running, and you can tell that you at least got to the correct IP address. Disadvantage is that you have to find some other, non-MQ way to automatically start the listener up when the machine starts up.
Regardless of which model you use for your MQ TCP/IP listener, you can have multiple ports and independently start-able and stop-able listeners. DEFINE multiple listener objects, or directly start multiple runmqlsr processes using different -p parameters.
As a beginner, you are probably quite OK to just use the DEFINE LISTENER command - perhaps practice with using something other than port 1414. A lot of beginners forget to start their listener after a queue manager restart, so that CONTROL(QMGR) setting is very handy for that. And then later, as you get more experienced, you can decide whether either of the above models suits your environment better.
Cheers,
Morag
_________________
Morag Hughson @MoragHughson
IBM MQ Technical Education Specialist
Get your IBM MQ training here!
MQGem Software |
|
| Back to top |
|
|
| hdomin257 |
| Posted: Tue Oct 26, 2021 12:17 am Post subject: |
|
|
Newbie
Joined: 27 Nov 2020
Posts: 7
|
Thank you for these beautiful answers.
I get it a lot more right now, but still struggle to connect all of the dots.
I understand these two models for running listeners.
-with runmqlsr I use the "second" model - direct run of runmqlsr process - it's kind of "standalone", can run with QM stopped. But It can't run under QM control, can't have controlled starts/stops by QM starts/stops. It lives it's own life and can be stopped by endmqlsr.
Listener object arrived later and added the functionality for controlled startups, shutdowns by QM, and also manual control using START LISTENER and STOP LISTENER mqsc's.
-But I can't tell if it fits model 1.) or model 2.) mentioned ways of running.
It seems both, cuz we can define CONTROL(STARTONLY) or (MANUAL) and it should run after QM stop.
Or not?
sorry I can't try this thing right know. THX a lot for explanations. |
|
| Back to top |
|
|
| hughson |
| Posted: Tue Oct 26, 2021 12:42 am Post subject: |
|
|
Padawan
Joined: 09 May 2013
Posts: 1914
Location: Bay of Plenty, New Zealand
|
| hdomin257 wrote: |
Listener object arrived later and added the functionality for controlled startups, shutdowns by QM, and also manual control using START LISTENER and STOP LISTENER mqsc's.
-But I can't tell if it fits model 1.) or model 2.) mentioned ways of running. |
It is model 1. "Create a listener object ...."
Listener objects do not run outside of the lifetime of the queue manager.
Cheers,
Morag
_________________
Morag Hughson @MoragHughson
IBM MQ Technical Education Specialist
Get your IBM MQ training here!
MQGem Software |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Tue Oct 26, 2021 5:58 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9396
Location: US: west coast, almost. Otherwise, enroute.
|
In the old days, we often found ourselves with orphaned listener processes - runmqlsr instances alive for which the qmgr instance was no longer running.
The solution to this was the invention of the listener OBJECT, which can (should) be defined such the listener process starts and ends with the qmgr instance.
Manually started (at a shell) runmqlsr process and automatically started as an object effectively yield the same results - a listener.
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| gbaddeley |
| Posted: Tue Oct 26, 2021 2:40 pm Post subject: |
|
|
Jedi
Joined: 25 Mar 2003
Posts: 2494
Location: Melbourne, Australia
|
There is an alternative for *NIX platforms, using the inet daemon, which was mainstream MQ config over 20 years ago. I went searching for it, and found it is still supported!
https://www.ibm.com/docs/en/ibm-mq/9.2?topic=linux-using-tcpip-listener-aix
Cons: Requires root access to configure. Superseded by LISTENER object.
FWIW, all our qmgrs in all environments have standard build config:
| Code: |
define listener('LISTENER1') trptype(tcp) replace +
port(nnnn) control(qmgr)
start listener('LISTENER1') |
We use non standard port numbers in many cases.
_________________
Glenn |
|
| Back to top |
|
|
| hdomin257 |
| Posted: Tue Oct 26, 2021 10:43 pm Post subject: |
|
|
Newbie
Joined: 27 Nov 2020
Posts: 7
|
| hughson wrote: |
Listener objects do not run outside of the lifetime of the queue manager.
|
So, what this property is doing? CONTROL(STARTONLY)
" If you want the listener to start when the queue manager starts but not stop when the queue
manager stops, specify the CONTROL(STARTONLY) property."
My last question on this topic, I will not bother anymore - these are the things which I should try, not annoyingly ask  |
|
| Back to top |
|
|
| hughson |
| Posted: Wed Oct 27, 2021 1:24 am Post subject: |
|
|
Padawan
Joined: 09 May 2013
Posts: 1914
Location: Bay of Plenty, New Zealand
|
| hdomin257 wrote: |
| hughson wrote: |
Listener objects do not run outside of the lifetime of the queue manager.
|
So, what this property is doing? CONTROL(STARTONLY)
" If you want the listener to start when the queue manager starts but not stop when the queue
manager stops, specify the CONTROL(STARTONLY) property."
My last question on this topic, I will not bother anymore - these are the things which I should try, not annoyingly ask |
You are quite correct, I had forgotten about CONTROL(STARTONLY). This does indeed leave the listener running (you can still see the runmqlsr process) even after the queue manager has stopped. So this is very like using the runmqlsr command directly. Take care upon queue manager restart because you will see an error message in the AMQERR01.LOG where the queue manager tries to start the listener again, only to discover that it is already there.
Cheers,
Morag
_________________
Morag Hughson @MoragHughson
IBM MQ Technical Education Specialist
Get your IBM MQ training here!
MQGem Software |
|
| Back to top |
|
|
| hdomin257 |
| Posted: Wed Oct 27, 2021 2:31 am Post subject: |
|
|
Newbie
Joined: 27 Nov 2020
Posts: 7
|
Thank You, all of you helped me understand it a lot more.
have a nice day. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Thu Oct 28, 2021 6:52 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9396
Location: US: west coast, almost. Otherwise, enroute.
|
| hdomin257 wrote: |
| My last question on this topic, I will not bother anymore - these are the things which I should try, not annoyingly ask |
You should consider getting formal hands-on MQ system admin training. For example https://www.ibm.com/training/course/WM156G
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| hughson |
| Posted: Thu Oct 28, 2021 12:15 pm Post subject: |
|
|
Padawan
Joined: 09 May 2013
Posts: 1914
Location: Bay of Plenty, New Zealand
|
|
| 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
|
|
|
|
