| Author |
Message
|
| TonyD |
 Posted: Wed Oct 03, 2001 4:15 pm Post subject: |
 |
|
Knight
Joined: 15 May 2001
Posts: 540
Location: New Zealand
|
| We are looking at using a single machine for Control Centre access to the separate System Test and Production environments (for valid reasons). It appears however that if one is connected to a CM and connects to a different CM both connections will be active concurrently and that any command (such as a Delete) will be passed to BOTH CMs! This situation can be avoided by stopping/starting the CC before doing a connection. However there is still a risk that someone might forget to do this. Can anyone suggest how I can ensure that the CC can only be connected to one CM at a time and that a second attempt to connect is rejected? |
|
| Back to top |
|
 |
| kolban |
| Posted: Wed Oct 03, 2001 7:22 pm Post subject: |
|
|
Grand Master
Joined: 22 May 2001
Posts: 1072
Location: Fort Worth, TX, USA
|
| This sounds like quite a serious bug. Have you called this in to IBM defect support? I would hope that connecting to a different CM caused the drop of the connection to the previous one. |
|
| Back to top |
|
|
| TonyD |
| Posted: Sun Oct 07, 2001 5:48 pm Post subject: |
|
|
Knight
Joined: 15 May 2001
Posts: 540
Location: New Zealand
|
After carrying out some testing I now think I was wrong in thinking that a CC command had been propagated to two CMs...have not been able to explain an in-house situation where it appeared to happen and a resource disappeared from two CMs but I have not been able to make it happen again.
Nevertheless it would be useful I think if the Control Centre screens indicated the current connection details. |
|
| Back to top |
|
|
| PeteHanbury |
| Posted: Tue Apr 20, 2004 6:29 am Post subject: UPDATE |
|
|
Novice
Joined: 13 Apr 2004
Posts: 23
Location: US AND EUROPE
|
THIS PROBLEM CAN BE AVOIDED BY SETTING THE ADOPTNEWMCA PARAMETERS WITHIN MQSERIES
_________________
PeteHanbury
Independent IBM MQSeries/MQSI Architecture Certified Contractor |
|
| Back to top |
|
|
| MikeC |
| Posted: Tue Apr 20, 2004 7:25 am Post subject: |
|
|
Acolyte
Joined: 30 Jun 2003
Posts: 55
Location: Toronto, Canada
|
We've had a similar problem connecting to different CMs from the same Control Center.
Pete,
How would you set the ADOPTNEWMCA parameter? .. Isn't the Message Channel Agent just a way to spread messages between distributed queue managers? How will it effect the client connection between the CC and the CM?
_________________
-Mike. |
|
| Back to top |
|
|
| PeteHanbury |
| Posted: Tue Apr 20, 2004 8:07 am Post subject: AdoptNeweMCA |
|
|
Novice
Joined: 13 Apr 2004
Posts: 23
Location: US AND EUROPE
|
I discovered this facility whilst working with Dick Hamilton one of the old Gurus from MQSeries at the MQSeries suppoort centre in Raliegh. Great guy whom i learnt a lot from. Setting this littel flag actually solves loads of problems. (Not just with the channels) I recently recommended it to a client using as/400 in Italy. They felt it would make no difference to their problem but were persuaded to use it. Two weekes later they came back to me and said it has solved al the problems they were experiencing and they are putting it into production.
The corect term one would use to descibe the problem 'described' is 'orphan client' This happens when a connection goes down and yet the reciever side does not know that it has been disconnected. It is the same througout MQSeries you have many internal operation doing things like hconn. But sometimes they fail to disconnect properly and over time you get memory leaks. This was a common problem with earlier versions of MQSI because developers were writing MQCLose into there code but not MQDISC. This problem is compounded by doing an endmqm -i which often leads loads of associated process's and applications hanging.
My advice is the following ... go to the google and search adoptnewmca or folow this link to see more details.
http://www-306.ibm.com/software/integration/mqfamily/library/manualsa/amqzag/amqzag2j.htm
If you select the ALL option you will find that this will clear the problem you are experiencing. It will kill any old threads or connections left over from the last connection with the CC.
Im not sure i have explained this well .. but basically the old connection does not know he has been killed and many of its processes are still running. These then confuse the CC whom uses them by mistake and connects to an old session.
Thus i would set the following
AdoptNewMCATimeout=120
AdoptNewMCACheck=ALL
Let me know how it goes
Finally if you are using the tcp keep alive option then set that to NO because it is largely redundant now and can cause this problem.
_________________
PeteHanbury
Independent IBM MQSeries/MQSI Architecture Certified Contractor |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Tue Apr 20, 2004 8:10 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
The only times I had any issues with using the same Control Center to talk to different CMs was when I did not ALSO change my workspace when I changed the connection.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Tue Apr 20, 2004 8:44 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7716
|
| Quote: |
Finally if you are using the tcp keep alive option then set that to NO because it is largely redundant now and can cause this problem.
|
KeepAlive is still valuable when dealing with situations where Heartbeats are not being sent, such as client channels outside of an MQGET with Wait, or on other channel types where one of the partners refuses to set HBInterval, and so the channel runs without HBs.
Adopting the MCA is great, I use it everywhere, but do remember it introduces a small security risk (someone can hijack your channel). AdoptNewMCACheck=ALL does help minimize this risk, since it makes it that much harder to impersonate the other side.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
|
|
