| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| amqrfdm flag question |
« View previous topic :: View next topic » |
| Author |
Message
|
| meaton78 |
 Posted: Tue Mar 03, 2009 11:12 am Post subject: amqrfdm flag question |
 |
|
Centurion
Joined: 16 Oct 2008
Posts: 100
|
I understand amqrfdm is pretty much an undocumented app, but I'm hoping someone can shed some light on some research I'm trying to do on a clustering issue.
On a single queue manager - QM1, I had a cluster queue - Q1 expire. The cluster queue has 12 instances across 12 queue managers. 6 are put inhibited and the other 6 are not. QM1 almost never uses Q1 since it is a batch job that runs on a single box. According to amqrfdm, the subscription expired and QM1 started dropping it's records of Q1. Of course, we had a need to use Q1 on QM1 and it only had records left of the put inhibited queues. The flag I am curious about it QFlags(0: ). I am noticing a bunch of qc definitions on that box had QFlags(0: ) and a bunch of others have QFlags(2: Refresh ). Can someone explain the difference between the two? I'm just wondering if we were about to lose a bunch more queues that are used on a regular basis.
QALIAS(Q1 ) 2 Live Seq(2
@667C Clusters @16EF0
QDesc( )
UUID(QMBROKER_2006-05-09_09.35.43 )
DefBind(0) DefPersistence(0) DefPriority(0) InhibitPut(1)
CLWLQueuePriority(0) CLWLQueueRank(0)
QFlags(0: )
Flags(1) MsgId(XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXx)
Prev(0 ) Next(0 ) Ascii(0 ) Qmgr(0 )
Cluster(CLUSTER ) Live Seq(2
@16EF0 Next(0 )
Exp(Fri Dec 12 08:47:53 EST 2008) Upd(Mon Jul 21 11:45:04 EST 2008)
QFlags(0: ) |
|
| Back to top |
|
 |
| fjb_saper |
| Posted: Tue Mar 03, 2009 8:39 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
If you look in the qmgr logs you should see a warning that the information for queue has not been refreshed over x many days before the qmgr drops any cluster queue.
Running a refresh cluster on the PR will usually update that information.
If communications are normal between the FR and PR you should always have access to the information in the FR and this should not happen.
If communications have been interrupted for whatever reason you may see this. This is then a good time to make sure that the information can flow freely between FR and PR and maybe to do a refresh cluster on the PR. ( I got an entry in the log with refreshing 403 objects and publishing 2)
Further a dis qc(*) all will have a field with how recent the information on the qc is. (date).
Remember as well that in your case the PR would have made a request to the FR to get all instances of the queue before completing the put or issuing a non zero RC.
Enjoy 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| meaton78 |
| Posted: Wed Mar 04, 2009 6:14 am Post subject: |
|
|
Centurion
Joined: 16 Oct 2008
Posts: 100
|
| Quote: |
Remember as well that in your case the PR would have made a request to the FR to get all instances of the queue before completing the put or issuing a non zero RC.
|
I don't understand this piece. The PR was starting to drop its definitions of Q1 since they had expired, but there were still 5 remaining, all of which were put inhibited. Since the PR still had knowledge of the qc, it tried to make the put, which failed. Doesn't the PR only make the request to the FR if it has no existing definitions of the qc?
According to the logs, there was a communication issue on 1/24. Even if there was a communication issue, wouldn't the messages just build up on the SCTQ on the FR and wait for the connection to be established? I guess I just don't fully understand how the expiration works.
I did also open a PMR last night just so they could look over the full amqrfdm dump that I took before the refresh cluster. |
|
| Back to top |
|
|
| vol |
| Posted: Wed Mar 04, 2009 11:50 am Post subject: |
|
|
Acolyte
Joined: 01 Feb 2009
Posts: 69
|
|
| Back to top |
|
|
| meaton78 |
| Posted: Wed Mar 04, 2009 5:02 pm Post subject: |
|
|
Centurion
Joined: 16 Oct 2008
Posts: 100
|
Just in case anyone wants to know:
The 0 QFlag just means there are no flags set. The 2:Refresh means
Subscription needs to be refreshed because the queue has been used since
the last refresh. This is normal and you will always see both in a
repository dump. |
|
| 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
|
|
|
|
