MQSeries.net :: View topic - multiple listeners for same queue manager

MQSeries.net

Tech Exchange

Education

Certifications

Library

Info Center

SupportPacs

FAQÂ Â

Usergroups

RSS Feed - WebSphere MQ Support

RSS Feed - Message Broker Support

MQSeries.net Forum Index » General Discussion » multiple listeners for same queue manager

Goto page 1, 2 Next

multiple listeners for same queue manager

« View previous topic :: View next topic »

Author

Message

snatus

Posted: Thu May 12, 2005 6:28 am Post subject: multiple listeners for same queue manager

Novice

Joined: 10 May 2003
Posts: 11

Hi,

Can I define multiple listeners running on different ports for the same queue manager in Linux? If yes, how can SVRCONN and CLNTCONN channels be set ? In other words, what needs to be done from MQ Server side so that there can be multiple CLNTCONN channels on MQClient side running on different ports? Does specifying multiple listeners for a queue manager have any disadvantages?

Thanks

Sandy

jefflowrey

Posted: Thu May 12, 2005 6:42 am Post subject:

Grand Poobah

Joined: 16 Oct 2002
Posts: 19981

Each listener needs it's own unique network address - usually this just means a unique port, but it could mean that you have one listener for TCP and one for SNA and one for MagicNetworkProtocol#12 or it could mean that you have one for port 1414 on a 192 network and one for 1414 on a public interface.

Each client will have to use a valid network address for a listener. The same client could, theoretically, connect to different listeners for the same qmgr - although why? I don't know off the top of my head if you can limit a SVRCONN/CLNTCONN channel pair to only be valid to a particular listener - I doubt it, though. So any client could use any channel it had authority on to talk to any listener - based on the address/port specified.

The disadvantages of multiple listeners is increased system resource useage.
_________________
I am *not* the model of the modern major general.

snatus

Posted: Thu May 12, 2005 6:45 am Post subject:

Novice

Joined: 10 May 2003
Posts: 11

Thanks for the quick reply.Actually, I got this requst from my development team.They want to use TCP/IP 1414 port to get messages via CLNTCONN and TCP/IP 1415 port to send messages to same qmgr.

Not sure if I can have 2 listeners with 2 different TCP/IP ports for same queue manager.

jefflowrey

Posted: Thu May 12, 2005 6:51 am Post subject:

Grand Poobah

Joined: 16 Oct 2002
Posts: 19981

snatus wrote:

You can.

But what they want doesn't make any sense, tell them to go back and read the APG again.

EDIT: What they want, likely, is the LOCALADDR port on the channel definitions.
_________________
I am *not* the model of the modern major general.

snatus

Posted: Thu May 12, 2005 6:58 am Post subject:

Novice

Joined: 10 May 2003
Posts: 11

I am kinda new to MQ.I checked the manual for SVRCONN channel definition.It doesn't have CONNAME attribute.So if I have 2 listeners with different ports running and define 1 SVRCONN channel on MQServer,how does the application connect via CLNTCONN (WAS application)?Can they specify port# while connecting or do I have to explicitly define CLNTCONN channel definition with CONNAME at my end?

jefflowrey

Posted: Thu May 12, 2005 7:05 am Post subject:

Grand Poobah

Joined: 16 Oct 2002
Posts: 19981

They have to specify the port # when connecting, in some way or another.

How they do this depends entirely on what their code is doing and in what language.

Again, I think you are fine with one listener, on port 1414, and set the localaddr property on the svrconn to 1415.

If that is NOT what they want (that the client makes an outbound connection to 1414 and receives inbound data on 1415 - through one connection to one listener), then tell them they don't know what they're talking about.
_________________
I am *not* the model of the modern major general.

snatus

Posted: Thu May 12, 2005 7:27 am Post subject:

Novice

Joined: 10 May 2003
Posts: 11

Just to verify I understood it correct:

Define 1 listener running on port 1414.Define 1 SVRCONN channel definition.Define 1 CLNTCONN channel definition and specify 1414 in CONNAME attribute and 1415 in LOCLADDR so that application gets msg on 1414 and sends thru 1415? (SVRCONN doesnot have LOCLADDR attribute)

Correct me if I am wrong.Thanks

jefflowrey

Posted: Thu May 12, 2005 7:47 am Post subject:

Grand Poobah

Joined: 16 Oct 2002
Posts: 19981

snatus wrote:

Well. If the svrconn doesn't have a localaddr (and it makes sense that it wouldn't), then it's really all up to them. The client connection channel is always defined by the client.

If they are using the MQSERVER environment variable to define their client connection, then they can't use the LOCLADDR attribute at all.

If they are using Java or JMS, then they may or may not be able to set this - I don't remember if the interfaces allow for specifying a LOCLADDR.

If they are using any form of the MQCONNX, then you will need to export or share your client connection table files to them, and then they will use the LOCLADDR you defined.

You can go through and read the Clients manual for some of this stuff.
_________________
I am *not* the model of the modern major general.

PeterPotkay

Posted: Thu May 12, 2005 4:20 pm Post subject:

Poobah

Joined: 15 May 2001
Posts: 7722

I have multiple Listeners on my Edge Queue Manager. Each incoming connection from another company has its own RCVR channel, and each company is told to use a specific port into my QM. Firewall rules prevent them from trying others.

If I get a problem where I have to immediatly shut off a connection from one of them, I stop their listener. Even if their channel continues to bomabard me with reconnect attempts (a D.O.S. attack maybe?), the other companies are not efffected, as their Listeners are not having to deal with all these connection attempts.
_________________
Peter Potkay
Keep Calm and MQ On

fjb_saper

Posted: Thu May 12, 2005 6:26 pm Post subject:

Grand High Poobah

Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY

Peter,

Can you please explain the advantage of shutting down the listener vs shutting down the channel.

Thanks

PeterPotkay

Posted: Thu May 12, 2005 7:05 pm Post subject:

Poobah

Joined: 15 May 2001
Posts: 7722

A listener has a limited number of outstanding connection attempts it can handle (see ListenerBackLog in the qm.ini file). If this threshold is exceeded, as it could easily be in a Denial of Service attack, all MQ connections will be refused. By running dedicated listeners for each outside Queue Manager, this threat is eliminated.
_________________
Peter Potkay
Keep Calm and MQ On

vennela

Posted: Tue May 17, 2005 6:13 am Post subject:

Jedi Knight

Joined: 11 Aug 2002
Posts: 4055
Location: Hyderabad, India

What happens when you issue endmqlsr for that particular QMGR having multiple listeners?
Will all of them go down?

PeterPotkay

Posted: Tue May 17, 2005 1:16 pm Post subject:

Poobah

Joined: 15 May 2001
Posts: 7722

Vennela, I have only ever done it on Windows, where the GUI allows you to selectivly end a particular Listener.

I see your point though for non Windows QMs......
_________________
Peter Potkay
Keep Calm and MQ On

bower5932

Posted: Tue May 17, 2005 1:29 pm Post subject:

Jedi Knight

Joined: 27 Aug 2001
Posts: 3023
Location: Dallas, TX, USA

Well, I just started my qmgr with 2 listeners. Here is my endmqlsr command:

Code:

C:\Documents and Settings\Administrator>endmqlsr -m pubsub.qmgr
2 WebSphere MQ listeners will end shortly.

PeterPotkay

Posted: Tue May 17, 2005 1:36 pm Post subject:

Poobah

Joined: 15 May 2001
Posts: 7722

Yeah, but the benifit for me is being able to selectivly kill listeners if one of them is being hammered. On Windows, theu MQ Services, its easy. Thru the command line, I think its impossible. Unless you kill the process directly???
_________________
Peter Potkay
Keep Calm and MQ On

Display posts from previous:

Goto page 1, 2 Next

Page 1 of 2

MQSeries.net Forum Index » General Discussion » multiple listeners for same 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