ASG
IBM
Zystems
Cressida
Icon
Netflexity
 
  MQSeries.net
Search  Search       Tech Exchange      Education      Certifications      Library      Info Center      SupportPacs      LinkedIn  Search  Search                                                                   FAQ  FAQ   Usergroups  Usergroups
 
Register  ::  Log in Log in to check your private messages
 
RSS Feed - WebSphere MQ Support RSS Feed - Message Broker Support

MQSeries.net Forum Index » General IBM MQ Support » AMQ9456 - we are receiving a lot of this messages RESOLVED

Post new topic  Reply to topic
 AMQ9456 - we are receiving a lot of this messages RESOLVED « View previous topic :: View next topic » 
Author Message
jeevan
PostPosted: Wed Dec 03, 2014 11:56 am    Post subject: AMQ9456 - we are receiving a lot of this messages RESOLVED Reply with quote

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
View user's profile Send private message
mqjeff
PostPosted: Wed Dec 03, 2014 12:00 pm    Post subject: Reply with quote

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
View user's profile Send private message
jeevan
PostPosted: Wed Dec 03, 2014 12:33 pm    Post subject: Reply with quote

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
View user's profile Send private message
JosephGramig
PostPosted: Thu Dec 04, 2014 7:10 am    Post subject: Reply with quote

Grand Master

Joined: 09 Feb 2006
Posts: 1231
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:
  1. How many FRs are there for the cluster?
  2. Does each FR have explicit cluster senders to each of the other FRs?
  3. Do the FRs also have (explicit) application objects on them?
Back to top
View user's profile Send private message AIM Address
tczielke
PostPosted: Thu Dec 04, 2014 10:25 am    Post subject: Reply with quote

Guardian

Joined: 08 Jul 2010
Posts: 939
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
View user's profile Send private message
jeevan
PostPosted: Thu Dec 04, 2014 1:11 pm    Post subject: Reply with quote

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:
  1. How many FRs are there for the cluster?
  2. Does each FR have explicit cluster senders to each of the other FRs?
  3. 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
View user's profile Send private message
jeevan
PostPosted: Tue Dec 09, 2014 5:59 am    Post subject: Reply with quote

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:
  1. How many FRs are there for the cluster?
  2. Does each FR have explicit cluster senders to each of the other FRs?
  3. 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
View user's profile Send private message
PeterPotkay
PostPosted: Tue Dec 09, 2014 8:37 am    Post subject: Reply with quote

Poobah

Joined: 15 May 2001
Posts: 7716

Question is will it reappear again in 30 days.
_________________
Peter Potkay
Keep Calm and MQ On
Back to top
View user's profile Send private message
jeevan
PostPosted: Thu Dec 11, 2014 8:38 am    Post subject: Reply with quote

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
View user's profile Send private message
Display posts from previous:   
Post new topic  Reply to topic Page 1 of 1

MQSeries.net Forum Index » General IBM MQ Support » AMQ9456 - we are receiving a lot of this messages RESOLVED
Jump to:  



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
Protected by Anti-Spam ACP
 
 


Theme by Dustin Baccetti
Powered by phpBB © 2001, 2002 phpBB Group

Copyright © MQSeries.net. All rights reserved.