|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
 |
|
AMQ9456 - we are receiving a lot of this messages RESOLVED |
« View previous topic :: View next topic » |
Author |
Message
|
jeevan |
Posted: Wed Dec 03, 2014 11:56 am Post subject: AMQ9456 - we are receiving a lot of this messages RESOLVED |
|
|
Grand Master
Joined: 12 Nov 2005 Posts: 1432
|
We are receiving a lot of this message -->AMQ9456 in our partial repositories. However, we are able to use that particular cluster queue. This queue is being used everyday without any issue. That means, this seems a wrong message.
Out OS is Linux and MQ version is 7.1.0.5
Have any one of you come across to this ?
Thanks
J
Last edited by jeevan on Tue Dec 09, 2014 6:00 am; edited 1 time in total |
|
Back to top |
|
 |
mqjeff |
Posted: Wed Dec 03, 2014 12:00 pm Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008 Posts: 17447
|
And did you follow the two steps in the RESPONSE section of the description of AMQ9456? |
|
Back to top |
|
 |
jeevan |
Posted: Wed Dec 03, 2014 12:33 pm Post subject: |
|
|
Grand Master
Joined: 12 Nov 2005 Posts: 1432
|
mqjeff wrote: |
And did you follow the two steps in the RESPONSE section of the description of AMQ9456? |
yes, the qmgr and queue are being used everyday for our test so I can tell the cluster is functioning correctly.
Just for test, I issued refresh cluster command to one to the qmgrs, and it started all the channels, so there is no issue on cluster functioning
I also check that the amqrrmfa process is running on the queue managers where we have an issue.
I also checked a few more stuff eg. checked whether there is any issue in FRs, any queues are full any space or mem or any kind of issues but all are -ve.
=== hasty conclusion
i have nearly reached to a hasty conclusion that the repository manager process is not working ( though seems running). the reason behind is that when I refreshed the cluster, it did not update the objects rather it wiped them out from the local repo. I believe it would update. I also checked ibm doc and that is what I saw.
are there any other things to check ? |
|
Back to top |
|
 |
JosephGramig |
Posted: Thu Dec 04, 2014 7:10 am Post subject: |
|
|
 Grand Master
Joined: 09 Feb 2006 Posts: 1244 Location: Gold Coast of Florida, USA
|
If you issue: REFRESH CLUSTER('bla') REPOS(YES)
At a PR, that will dump all cluster info about that cluster at the PR and register its cluster objects with the FR it has an explicit cluster sender to or the first one it can successfully communicate with. When an FR receives a cluster update, it will only forward that cluster update to other FRs in the cluster to which it has an explicit cluster sender.
So the best place to issue the REFRESH CLUSTER('bla') REPOS(YES) would be at the Qmgr indicated in the msg about a missing update. Of course, if that is also a FR, then you know you have a broken cluster. Never issue REFRESH CLUSTER at an FR.
This is why it is best to have isolated FRs (two and only two) that host no application cluster objects. If need be, create them on machines that do host applicaiton Qmgrs.
I've seen the issue you are talking about and it tends to be a misconfiguration. It can be a defect that is usually resolved by maintenance.
Other thinks to check for the cluster in question:
- How many FRs are there for the cluster?
- Does each FR have explicit cluster senders to each of the other FRs?
- Do the FRs also have (explicit) application objects on them?
|
|
Back to top |
|
 |
tczielke |
Posted: Thu Dec 04, 2014 10:25 am Post subject: |
|
|
Guardian
Joined: 08 Jul 2010 Posts: 941 Location: Illinois, USA
|
FYI - I have noticed that we get these AMQ9456 that will be reported for one queue manager for several days and then just disappear with no administrative cluster actions taken. When I have dug into it, everything looked correct in the clustering configuration. I could be confusing this with another issue, but I am pretty sure I opened a PMR on this behavior and collected diagnostics, and nothing was found to be incorrect by IBM. At this point, I have chalked it up to some "odd" clustering behavior, since it does not result in any application or clustering issue that we are aware of, and is transient in nature. |
|
Back to top |
|
 |
jeevan |
Posted: Thu Dec 04, 2014 1:11 pm Post subject: |
|
|
Grand Master
Joined: 12 Nov 2005 Posts: 1432
|
JosephGramig wrote: |
If you issue: REFRESH CLUSTER('bla') REPOS(YES)
At a PR, that will dump all cluster info about that cluster at the PR and register its cluster objects with the FR it has an explicit cluster sender to or the first one it can successfully communicate with. When an FR receives a cluster update, it will only forward that cluster update to other FRs in the cluster to which it has an explicit cluster sender.
So the best place to issue the REFRESH CLUSTER('bla') REPOS(YES) would be at the Qmgr indicated in the msg about a missing update. Of course, if that is also a FR, then you know you have a broken cluster. Never issue REFRESH CLUSTER at an FR.
|
I agree with you and thought about that. I did not do that as we generally do not issue the refresh cluster command. In fact, we work slide differently. I have to prepare RCA kind of document, and agree with all party involved before we do anything on an issue.
But just for the sake of curiosity, I issued the REFRESH CLUSTER command in the PR which subscribes the queue ( does not host), and after that I have not see the message any more. I know there is no logic in this but this is happening.
JosephGramig wrote: |
This is why it is best to have isolated FRs (two and only two) that host no application cluster objects. If need be, create them on machines that do host application Qmgrs.
I've seen the issue you are talking about and it tends to be a reconfiguration. It can be a defect that is usually resolved by maintenance.
|
we also have cluster objects on the FRs.
When I looked at the details, we have mq fp 5 over mq 7.1 a month ago on 10/23 and the message we saw first time was a month after 11/23.
There was qmgr bounce definitely after bounce or restarted after the fp. But I hope, after bounce, the issue could go off.
JosephGramig wrote: |
Other thinks to check for the cluster in question:
- How many FRs are there for the cluster?
- Does each FR have explicit cluster senders to each of the other FRs?
- Do the FRs also have (explicit) application objects on them?
|
We have 2 FRs
Yes, FRS have explicit cluster sender channel
Yes, FRs also hold the queue in question. |
|
Back to top |
|
 |
jeevan |
Posted: Tue Dec 09, 2014 5:59 am Post subject: |
|
|
Grand Master
Joined: 12 Nov 2005 Posts: 1432
|
jeevan wrote: |
JosephGramig wrote: |
If you issue: REFRESH CLUSTER('bla') REPOS(YES)
At a PR, that will dump all cluster info about that cluster at the PR and register its cluster objects with the FR it has an explicit cluster sender to or the first one it can successfully communicate with. When an FR receives a cluster update, it will only forward that cluster update to other FRs in the cluster to which it has an explicit cluster sender.
So the best place to issue the REFRESH CLUSTER('bla') REPOS(YES) would be at the Qmgr indicated in the msg about a missing update. Of course, if that is also a FR, then you know you have a broken cluster. Never issue REFRESH CLUSTER at an FR.
|
I agree with you and thought about that. I did not do that as we generally do not issue the refresh cluster command. In fact, we work slide differently. I have to prepare RCA kind of document, and agree with all party involved before we do anything on an issue.
But just for the sake of curiosity, I issued the REFRESH CLUSTER command in the PR which subscribes the queue ( does not host), and after that I have not see the message any more. I know there is no logic in this but this is happening.
JosephGramig wrote: |
This is why it is best to have isolated FRs (two and only two) that host no application cluster objects. If need be, create them on machines that do host application Qmgrs.
I've seen the issue you are talking about and it tends to be a reconfiguration. It can be a defect that is usually resolved by maintenance.
|
we also have cluster objects on the FRs.
When I looked at the details, we have mq fp 5 over mq 7.1 a month ago on 10/23 and the message we saw first time was a month after 11/23.
There was qmgr bounce definitely after bounce or restarted after the fp. But I hope, after bounce, the issue could go off.
JosephGramig wrote: |
Other thinks to check for the cluster in question:
- How many FRs are there for the cluster?
- Does each FR have explicit cluster senders to each of the other FRs?
- Do the FRs also have (explicit) application objects on them?
|
We have 2 FRs
Yes, FRS have explicit cluster sender channel
Yes, FRs also hold the queue in question. |
========Bouncing the QMGR resolved the issue
I believe refresh cluster will do too
Last edited by jeevan on Thu Dec 11, 2014 8:40 am; edited 2 times in total |
|
Back to top |
|
 |
PeterPotkay |
Posted: Tue Dec 09, 2014 8:37 am Post subject: |
|
|
 Poobah
Joined: 15 May 2001 Posts: 7722
|
Question is will it reappear again in 30 days.  _________________ Peter Potkay
Keep Calm and MQ On |
|
Back to top |
|
 |
jeevan |
Posted: Thu Dec 11, 2014 8:38 am Post subject: |
|
|
Grand Master
Joined: 12 Nov 2005 Posts: 1432
|
PeterPotkay wrote: |
Question is will it reappear again in 30 days.  |
I do not think so but have to see.
We again has the same issue in another queue manager
this happenss when we upgrade to fp5, but did not happened immediately. so we can not relate directly to fp5, but it had not had this before
http://www-01.ibm.com/support/docview.wss?uid=swg1IZ51686 |
|
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
|
|
|
|