| Author |
Message
|
| jvdv |
 Posted: Thu Feb 28, 2013 7:34 pm Post subject: amqrmppa isolation (SVRCONN vs SENDER/RECEIVER Channels) |
 |
|
Newbie
Joined: 28 Feb 2013
Posts: 4
Location: Canberra, Australia
|
We have an application that connects via MQ-Client binding to a channel APP.SVRCONN on the mq server. The application makes 75 connections to the MQServer. No Exits installed on the SVRCONN channel.
The MQServer also have numerous SENDER/RECEIVER channel pairs connecting to various other partner’s QManagers. We do have exits in place on all the sender/receiver channel pairs that logs some message detail to flat file.
We know that the amqrmppa pooler process service both the receiver channels as well as the SVRCONN channels. After a recent upgrade (MQ 5.3 to MQ 7.1 / App Server binding to Client Binding) we found that the application is a lot less stable.
The app sometimes stop responding with mq error 2009/MQRC_CONNECTION_BROKEN. The problem was traced to the exits on the Sender/Reciver channel pairs. The exits would fail after a few hours of running. This would take the amqrmppa pooler process down and at that point the app would start to get the 2009 errors.
We will fix the exit, but I was wondering if it was possible to isolate the amqrmppa - APP.SVRCONN process from the amqrmppa – Sender/Reciver process. That way if we have a problem with the sender/receiver channel exits, it will not take down all the SVRCONN channels with it?
Any feedback will be greatly appreciated. |
|
| Back to top |
|
 |
| gbaddeley |
| Posted: Sun Mar 03, 2013 4:12 pm Post subject: |
|
|
Jedi Knight
Joined: 25 Mar 2003
Posts: 2538
Location: Melbourne, Australia
|
afaik, it is not possible to isolate the MCA threads for any particular types of channels or names of channels to run in any particular instance of the amqrmppa processes. The only recourse is to stabilise the exit so that it doesn't fall over.
_________________
Glenn |
|
| Back to top |
|
|
| mqjeff |
| Posted: Mon Mar 04, 2013 2:22 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| Glenn - I'm not entirely solid on this, but wouldn't spinning up a second listener create an additional process pool? |
|
| Back to top |
|
|
| jvdv |
| Posted: Mon Mar 04, 2013 4:34 pm Post subject: |
|
|
Newbie
Joined: 28 Feb 2013
Posts: 4
Location: Canberra, Australia
|
| mqjeff wrote: |
| spinning up a second listener create an additional process pool? |
Will do a bit more work on it but it look promising at this stage...
ptree on the listener...
[auser@mqmserver]/export/home/auser> ptree 9587
11937 zsched
..9573 /opt/mqm/bin/amqzxma0 -m XX3
....9580 /opt/mqm/bin/amqzmgr0 -m XX3
......9587 /opt/mqm/bin/runmqlsr -r -m XX3 -t TCP -p 1414
........9599 /opt/mqm/bin/amqrmppa -m XX3
........14221 /opt/mqm/bin/amqrmppa -m XX3
I will start up a few other channels on another listener on the same QManager and see if a new amqrmppa is spawned under the new listener and advise back. |
|
| Back to top |
|
|
| gbaddeley |
| Posted: Mon Mar 04, 2013 5:25 pm Post subject: |
|
|
Jedi Knight
Joined: 25 Mar 2003
Posts: 2538
Location: Melbourne, Australia
|
| mqjeff wrote: |
| Glenn - I'm not entirely solid on this, but wouldn't spinning up a second listener create an additional process pool? |
Hi Jeff. A second listener would run a second instance of the runmqlsr process. afaik, this doesn't start up any additional amqrmppa processes (MCA thread pool). I've never seen any hint that this might occur.
_________________
Glenn |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Tue Mar 05, 2013 5:48 am Post subject: Re: amqrmppa isolation (SVRCONN vs SENDER/RECEIVER Channels) |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
I copied in the below from the second thread that jvdv started by mistake. I deleted that other post since the info is now here.
| jvdv wrote: |
We have opened a new channel via another listener running on port 1413.
We were hoping that a new pooler process (amqrmppa) will be spawned by the listener. That did *NOT* happen! The solaris pfiles output indicates that the new channel is managed via one of the pooler process attached to the listener on port 1413. In other words it looks like a listener can offload channel management to a pooler process spawned by a listener other than itself.
sudo pfiles 14221
14221: /opt/mqm/bin/amqrmppa -m XX3
Current rlimit: 10000 file descriptors
.
.
Remove a lot of stuff
.
.
39: S_IFSOCK mode:0666 dev:366,0 ino:31636 uid:0 gid:0 size:0
O_RDWR|O_NDELAY
SOCK_STREAM
SO_REUSEADDR,SO_SNDBUF(49152),SO_RCVBUF(49680),IP_NEXTHOP(0.0.194.16)
sockname: AF_INET6 ::ffff:MQSERVER port: 1413
peername: AF_INET6 ::ffff:CLIENTMACHINE port: 61201 |
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| jvdv |
| Posted: Tue Mar 05, 2013 2:52 pm Post subject: Conclusion: Listeners do not have dedicated pooler process |
|
|
Newbie
Joined: 28 Feb 2013
Posts: 4
Location: Canberra, Australia
|
[auser@mqmserver]/export/home/auser> ps -ef | grep runmqlsr | grep XX3
.....mqm 9586 9580 0 Feb 28 ? 0:01 /opt/mqm/bin/runmqlsr -r -m XX3 -t TCP -p 1413
.....mqm 9587 9580 0 Feb 28 ? 0:20 /opt/mqm/bin/runmqlsr -r -m XX3 -t TCP -p 1414
.....mqm 9585 9580 0 Feb 28 ? 0:01 /opt/mqm/bin/runmqlsr -r -m XX3 -t TCP -p 1426
[auser@mqmserver]/export/home/auser> ptree 9586
11937 zsched
..9573 /opt/mqm/bin/amqzxma0 -m XX3
....9580 /opt/mqm/bin/amqzmgr0 -m XX3
......9586 /opt/mqm/bin/runmqlsr -r -m XX3 -t TCP -p 1413
[auser@mqmserver]/export/home/auser> ptree 9587
11937 zsched
..9573 /opt/mqm/bin/amqzxma0 -m XX3
....9580 /opt/mqm/bin/amqzmgr0 -m XX3
......9587 /opt/mqm/bin/runmqlsr -r -m XX3 -t TCP -p 1414
........9599 /opt/mqm/bin/amqrmppa -m XX3
........14221 /opt/mqm/bin/amqrmppa -m XX3
[auser@mqmserver]/export/home/auser> ptree 9585
11937 zsched
..9573 /opt/mqm/bin/amqzxma0 -m XX3
....9580 /opt/mqm/bin/amqzmgr0 -m XX3
......9585 /opt/mqm/bin/runmqlsr -r -m XX3 -t TCP -p 1426
Summary:
The new channels started via port 1413 and 1426 are managed via the existing amqrmppa (process id 14221).
See pfiles output for proof. |
|
| Back to top |
|
|
| ramires |
| Posted: Tue Mar 05, 2013 3:42 pm Post subject: |
|
|
Knight
Joined: 24 Jun 2001
Posts: 523
Location: Portugal - Lisboa
|
one possible solution is to define a new qmgr to isolate APP.SVRCONN channel. This queue manager will be like a gateway to the existing one, but this change depends on your topology, maybe not a feasible thing to implement.
_________________
Obrigado / Thanks you |
|
| Back to top |
|
|
|
|
