| Author |
Message
|
| issac |
 Posted: Mon Mar 28, 2011 6:13 pm Post subject: what's SYSTEM.CLUSTER.REPOSITORY.QUEUE's format? |
 |
|
Disciple
Joined: 02 Oct 2008
Posts: 158
Location: Shanghai
|
Hello, guys
I wish to read the data body of auto-generated messages inside SYSTEM.CLUSTER.REPOSITORY.QUEUE, SYSTEM.CLUSTER.COMMAND.QUEUE.
But it's hardly readable from output of amqsbcg.
Is there a way?
Thanks in advance!
_________________
Bazinga! |
|
| Back to top |
|
 |
| mqjeff |
| Posted: Mon Mar 28, 2011 6:16 pm Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
Uhm.
No?
Uhm.
Why?
What business requirement do you expect to meet by reading these messages, assuming it is actually possilble?
Why do you expect that this business requirement is not meetable without needing to read these messages... assuming it is actually possible? |
|
| Back to top |
|
|
| issac |
| Posted: Mon Mar 28, 2011 6:32 pm Post subject: aha, that's funny |
|
|
Disciple
Joined: 02 Oct 2008
Posts: 158
Location: Shanghai
|
Hello, mqjeff
Let's say it's kinda of personal curiosity.
When dealing with cluster problems, now and then commands don't take effect at once because they're done asynchronously.
As I'm not much satisfied with the waiting-for-another-5-minutes-then-see-if-it-worked approach, I intend to understand what MQ is doing by reading the next command message.
_________________
Bazinga! |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Mon Mar 28, 2011 6:43 pm Post subject: Re: aha, that's funny |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| issac wrote: |
Hello, mqjeff
Let's say it's kinda of personal curiosity.
When dealing with cluster problems, now and then commands don't take effect at once because they're done asynchronously.
As I'm not much satisfied with the waiting-for-another-5-minutes-then-see-if-it-worked approach, I intend to understand what MQ is doing by reading the next command message. |
I can understand the unwillingness to wait for another 5 mins...
I have found that usually (in small clusters < 12 qmgrs) sometimes the second FR qmgr is not updated right away. A refresh cluster seems to fix that, when it happens. (Keep in mind here that we have 3 FR's for geographical reasons).
Don't know that I would suggest this for a medium or large cluster though... Read somewhere that for clusters this size it is good practice to isolate the FR's and have them do no other duty but handle the FR traffic. This may improve greatly on the propagation of cluster information.
In any case, before doing a change that you think might not get propagated fast enough, make sure that the channel between the FRs are running fine. If need be you can start them manually...
Have fun 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| exerk |
| Posted: Mon Mar 28, 2011 11:36 pm Post subject: Re: aha, that's funny |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| issac wrote: |
| ...As I'm not much satisfied with the waiting-for-another-5-minutes-then-see-if-it-worked approach, I intend to understand what MQ is doing by reading the next command message... |
Patience seems to be a virtue that is somewhat lacking these days. Give clusters time and heed fjb_saper's advice in regard to channels; a number of things will affect propagation, e.g. server load, network load etc.
_________________
It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Tue Mar 29, 2011 2:01 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
All that said, and I agree with it.
Secondarily, the messages that are sitting around waiting are not the messages that are the source of the issue.
Particularly if they are messages piled up on SYSTEM.CLUSTER.COMMAND.QUEUE on an FR.
It's the message BEFORE the ones that are waiting around that are causing the problem.
Also, running a REFRESH CLUSTER in a medium or large sized cluster is a good way to cause this kind of delay - so don't do it unless you know that the whole cluster has the time to process it and that all the channels are running and etc. etc. etc. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Tue Mar 29, 2011 5:15 am Post subject: Re: aha, that's funny |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
| issac wrote: |
| When dealing with cluster problems, now and then commands don't take effect at once because they're done asynchronously. |
WMQ message delivery is asynchronous.
| Quote: |
| As I'm not much satisfied with the waiting-for-another-5-minutes-then-see-if-it-worked approach,... |
As discussed here, in a fully configured and operational cluster, much of the delay is due to the lack of processor availability.
| Quote: |
| I intend to understand what MQ is doing by reading the next command message. |
You can enroll in IBMs WM250 WebSphere MQ: Designing and Architecting Clustering Solutions course. A bit of how clusters work is part of this course. https://www-304.ibm.com/jct03001c/services/learning/ites.wss/us/en?pageType=course_description&courseCode=WM250
While we appreciate and applaud your curiosity, IMHO trying to fix clusters usually breaks them.
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| Mr Butcher |
| Posted: Tue Mar 29, 2011 5:24 am Post subject: |
|
|
Padawan
Joined: 23 May 2005
Posts: 1716
|
On distributed there is amqrfdm, which shows some more detailed cluster information then the mqsc display commands for queues and qmgrs. it should match with what is in the repository queue ....... although i think its not very useful to browse that. too many internals, too many unknown stuff.....
_________________
Regards, Butcher |
|
| Back to top |
|
|
|
|
