| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| Is there a way to release IPPROCS for one receive Q |
« View previous topic :: View next topic » |
| Author |
Message
|
| rsinha |
 Posted: Thu Apr 28, 2005 12:27 pm Post subject: Is there a way to release IPPROCS for one receive Q |
 |
|
Apprentice
Joined: 29 Aug 2003
Posts: 42
|
Hi,
We have one Q MGR with various Qs, and two clients on separate boxes, that connect to this Q MGR, using diff Qs. Recenetly, One of our client boxes died, while we were able to revive it after a while, we were not able to connect to MQ server for the receive Qs. The reson was that on the QMGR, IPPROCS were (1) for all receive Qs, I guess because when the client box went down abruptly, MQ didn't release the connection. So then we had to restart the Q MGR which released all IPPROCS and OPPROCS. But the result was, that the other client box, which was running fine was affceted too due to the restart.
In future, what steps can we take to release IPPROCS for a particular receive Q and OPPROCS for transmit Q. Is there a way to do without restarting th eQMGR. Also, I guess we can find out what's the PID of that IPPROC and kill the listener (runmqlsr) process that initiated that process. But that seems like a drastic measure to take, would killing a particular runmqlsr process impact the functioning of the rest of the QMGR, other that we having to restart the listener process.
Is there a better way to release the IPPROCS or OPPROCS? |
|
| Back to top |
|
 |
| vennela |
| Posted: Thu Apr 28, 2005 3:43 pm Post subject: |
|
|
Jedi Knight
Joined: 11 Aug 2002
Posts: 4055
Location: Hyderabad, India
|
|
| Back to top |
|
|
| JT |
| Posted: Thu Apr 28, 2005 8:00 pm Post subject: |
|
|
Padawan
Joined: 27 Mar 2003
Posts: 1564
Location: Hartford, CT.
|
| Quote: |
| what steps can we take to release IPPROCS for a particular receive Q |
Don't know if this will work in your situation, but possibly disabling the Get parameter on the receive queue will do the trick. |
|
| Back to top |
|
|
| rsinha |
| Posted: Thu Apr 28, 2005 9:30 pm Post subject: |
|
|
Apprentice
Joined: 29 Aug 2003
Posts: 42
|
No, disabling Get didn't release IPPROCS. This seams like a severe limitaion of MQ, that if you have multiple client connected to a Q MGr, and if IPPROCS on just one of the client's Q is not releaseD, all clients will be affected because the QMGR has to be restarted.
 |
|
| Back to top |
|
|
| Tibor |
| Posted: Fri Apr 29, 2005 3:12 am Post subject: |
|
|
Grand Master
Joined: 20 May 2001
Posts: 1033
Location: Hungary
|
| rsinha wrote: |
| No, disabling Get didn't release IPPROCS. This seams like a severe limitaion of MQ, that if you have multiple client connected to a Q MGr, and if IPPROCS on just one of the client's Q is not releaseD, all clients will be affected because the QMGR has to be restarted. |
It's depend on. If the applications are connecting through network (aka mq clients), you can stop the server-connection channels separately. But when someone is using a direct connection (through local agent process), you cannot disconnect it.
Tibor |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Fri Apr 29, 2005 4:13 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
What were you trying to do that you could not because IPROCS was not 0?
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| rsinha |
| Posted: Fri Apr 29, 2005 8:06 am Post subject: What were you trying to do that you could not because IPROCS |
|
|
Apprentice
Joined: 29 Aug 2003
Posts: 42
|
| well, the client host box that had died, after reviving it , when we tried to restart our client app on that box, it couldn't connect to the receive Qs, as IPPROCS for those Qs were (1). So, then to release it, we had to restart the QMGR, which affected the other client apps also. |
|
| Back to top |
|
|
| rsinha |
| Posted: Fri Apr 29, 2005 8:12 am Post subject: depend on. If the applications are connecting through networ |
|
|
Apprentice
Joined: 29 Aug 2003
Posts: 42
|
Yes this solution works. So all we need now is to have a separate SERVCONN channel for each of the client (so far we are using one for all clients) and in the event of one client box getting messed up, we can just stop and restart that servconn channel.
But if you simply stop channel(servconn_channel), that doesn't release the IPPROCS, we need to do stop channel(servconn_channel) mode(FORCE), that one works.
Thanx |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Fri Apr 29, 2005 9:28 am Post subject: Re: What were you trying to do that you could not because IP |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| rsinha wrote: |
| well, the client host box that had died, after reviving it , when we tried to restart our client app on that box, it couldn't connect to the receive Qs, as IPPROCS for those Qs were (1). So, then to release it, we had to restart the QMGR, which affected the other client apps also. |
Why are your applications opening the queue with MQOO_INPUT_EXCLUSIVE? Do they really need to be the only process that has that queue open? Can you use MQOO_INPUT_SHARED?
But we also have dedicated SVRCONN channels for each app. It is nice to be able to shut an app down from the MQ's perspective.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| Tibor |
| Posted: Mon May 02, 2005 1:23 am Post subject: Re: depend on. If the applications are connecting through ne |
|
|
Grand Master
Joined: 20 May 2001
Posts: 1033
Location: Hungary
|
| rsinha wrote: |
Yes this solution works. So all we need now is to have a separate SERVCONN channel for each of the client (so far we are using one for all clients) and in the event of one client box getting messed up, we can just stop and restart that servconn channel.
But if you simply stop channel(servconn_channel), that doesn't release the IPPROCS, we need to do stop channel(servconn_channel) mode(FORCE), that one works. |
There is a way to disconnect unique client, one at a time:
| Code: |
| STOP CHANNEL(<chlname>) CONNAME(<address/name>) |
And Peter is right, only one server-connection channel is not a good idea.
Tibor |
|
| 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
|
|
|
|
