| Author |
Message
|
| vennela |
 Posted: Tue Dec 21, 2004 1:21 pm Post subject: What is amqrmppa process |
 |
|
Jedi Knight
Joined: 11 Aug 2002
Posts: 4055
Location: Hyderabad, India
|
I looked at the System Admin manual and it says it is the recevier process. But I looked at the running amqrmppas on one of the AIX boxes where QMGR is running and it is having bunch of amqrmppa processes.
Now some of them have the parent process id as runmqlsr, which makes sense.
Some of the others have PPID as the PID of the runmqchi process. So, is this process for both the incoming and outgoing channels?
Also the transmit queues are opened by amqrmppa processes.
Does this mean that this process is for both incoming and outgoing channels. |
|
| Back to top |
|
 |
| csmith28 |
| Posted: Tue Dec 21, 2004 1:27 pm Post subject: |
|
|
Grand Master
Joined: 15 Jul 2003
Posts: 1196
Location: Arizona
|
I think it's for RCVR and SVRCONN Channels. Each instance of the amqrmppa can handle as many as 64 connections.
I think. 
_________________
Yes, I am an agent of Satan but my duties are largely ceremonial. |
|
| Back to top |
|
|
| vennela |
| Posted: Tue Dec 21, 2004 1:51 pm Post subject: |
|
|
Jedi Knight
Joined: 11 Aug 2002
Posts: 4055
Location: Hyderabad, India
|
| csmith28 wrote: |
I think it's for RCVR and SVRCONN Channels. Each instance of the amqrmppa can handle as many as 64 connections.
I think. |
I am convinced that it will be used for RCVRs and SVRCONNs. What about outgoing channels. What about the XMITQs being opened by amqrmppa process. |
|
| Back to top |
|
|
| csmith28 |
| Posted: Tue Dec 21, 2004 1:56 pm Post subject: |
|
|
Grand Master
Joined: 15 Jul 2003
Posts: 1196
Location: Arizona
|
Well, I just did a dis qstatus on a couple of my prod XMITQ's and all I see is a runmqchl_d process attached to them. Which I would expect because all of my Clients put messages to QAliases that point to QRemotes.
Could it be that you have Client Applications putting messages directly to your XMITQ?
_________________
Yes, I am an agent of Satan but my duties are largely ceremonial. |
|
| Back to top |
|
|
| vennela |
| Posted: Tue Dec 21, 2004 2:00 pm Post subject: |
|
|
Jedi Knight
Joined: 11 Aug 2002
Posts: 4055
Location: Hyderabad, India
|
What version of MQ. I think this process is new to MQ 5.3
Also in the channel definition what is the MCATYPE? Is it PROCESS or THREAD?
How did you start the channel? using the control command runmqchl or using MQSC command START CHANNEL? |
|
| Back to top |
|
|
| csmith28 |
| Posted: Tue Dec 21, 2004 2:14 pm Post subject: |
|
|
Grand Master
Joined: 15 Jul 2003
Posts: 1196
Location: Arizona
|
| vennela wrote: |
What version of MQ. I think this process is new to MQ 5.3
Also in the channel definition what is the MCATYPE? Is it PROCESS or THREAD?
How did you start the channel? using the control command runmqchl or using MQSC command START CHANNEL? |
AIX5.1.0
MQ5.3.0.6
The channels are started from TRIGGERING so the runmqchi process calls
/usr/mqm/bin/runmqchl -c SDR.CHANNEL.NAME
MCATYPE(PROCESS)
_________________
Yes, I am an agent of Satan but my duties are largely ceremonial. |
|
| Back to top |
|
|
| csmith28 |
| Posted: Tue Dec 21, 2004 2:53 pm Post subject: |
|
|
Grand Master
Joined: 15 Jul 2003
Posts: 1196
Location: Arizona
|
Found this on Google:
New channel behavior in WebSphere MQ
By default, in WebSphere MQ 5.3, threaded channels started by the channel
initiator or a listener do not run under that process, but under a process
called AMQRMPPA, otherwise known as a pool process.
To revert to the MQSeries 5.2 behavior, and have channels run under the
originating process, define an environment variable MQNOREMPOOL. The
existence of this variable, set to any value, runs the channel threads as
part of the listener or channel initiator process. This can be useful when
trying to isolate one or more channels from the rest of the configuration,
for example when testing channel exits.
And this:
In WebSphere MQ 5.3, why is runmqlsr now the recommended listener over inetd?
A: 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.
_________________
Yes, I am an agent of Satan but my duties are largely ceremonial. |
|
| Back to top |
|
|
| vennela |
| Posted: Tue Dec 21, 2004 2:59 pm Post subject: |
|
|
Jedi Knight
Joined: 11 Aug 2002
Posts: 4055
Location: Hyderabad, India
|
I did some testing and this is the behaviour:
I put the MCATYPE as THREAD and the XMITQ is opened by amqrmppa
I put the MCATYPE as PROCESS and the XMITQ is opened by runmqchl
That along with the above exlanation makes me believe that this process is used for both outgoing and incoming channels.
Thank you. |
|
| Back to top |
|
|
| csmith28 |
| Posted: Tue Dec 21, 2004 3:08 pm Post subject: |
|
|
Grand Master
Joined: 15 Jul 2003
Posts: 1196
Location: Arizona
|
| vennela wrote: |
I did some testing and this is the behaviour:
I put the MCATYPE as THREAD and the XMITQ is opened by amqrmppa
I put the MCATYPE as PROCESS and the XMITQ is opened by runmqchl
That along with the above exlanation makes me believe that this process is used for both outgoing and incoming channels.
Thank you. |
Well in the case of RCVR and SVRCONN Channels I would agree but I don't think this is the Case for SDR Channels. I am not sure about SVR RQSTR chltypes. I haven't used them often enough.
_________________
Yes, I am an agent of Satan but my duties are largely ceremonial. |
|
| Back to top |
|
|
| csmith28 |
| Posted: Tue Dec 21, 2004 3:28 pm Post subject: |
|
|
Grand Master
Joined: 15 Jul 2003
Posts: 1196
Location: Arizona
|
Just found this
runmqchl controls any locally started channel over any protocol - Could be SDR, SVR, CLUSSDR or RQSTR.
so I'm thinking (by process of elimination) that means RCVR, CLUSRCVR, SVR and SVRCONN Channels are controlled by the amprmppa process.
That and my Process by Platform Document says amqrmppa is a "Channel Receiver process" which would lead me to believe that it controls any channel capable of receiving a message.
Asside from the MCA intercommunication with it's remote partner is a SDR Channel able to receive a message?
_________________
Yes, I am an agent of Satan but my duties are largely ceremonial. |
|
| Back to top |
|
|
| Nigelg |
| Posted: Tue Dec 21, 2004 10:01 pm Post subject: |
|
|
Grand Master
Joined: 02 Aug 2004
Posts: 1046
|
amqrmppa runs any type of channel, including SDRs.
RCVR and SVRCONN channels are run in amqrmppa if using runmqlsr (rather than inetd).
If MCATYPE is THREAD on a SDR channel, the channel is run as a thread in amqrmppa. |
|
| Back to top |
|
|
|
|
