Author |
Message
|
jefflowrey |
Posted: Thu Dec 22, 2005 5:18 pm Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002 Posts: 19981
|
clindsey wrote: |
It could be that you want a local copy on QMGRA of all messages that are put to QRemote. Then you would set up mirrorq on QMGRA with the source queue being QRemote and the target being some other local queue. It is also possible for the target to also be another remote queue definition on QMGRA. |
This is the scenario I wasn't sure about. This is possible, then. Excellent.
Thanks. _________________ I am *not* the model of the modern major general. |
|
Back to top |
|
 |
DAS |
Posted: Fri Dec 23, 2005 2:05 am Post subject: |
|
|
Apprentice
Joined: 15 Aug 2005 Posts: 30
|
Nice that I can save you some time
Thanks Charlie and Jeff for your question!
The last scenario which Jeff mean was indeed also the one I meant.
I was a bit scared that remote queues could not be mirrored, but now I see all possibilities. This means we don't have to revert to the mirroring of transmission queues and to stress it even further, we can have ONE central mirroring facility where we install the API exit only for one central queue manager that only holds definitions of remote queues.
That's great
I still have one minor question though:
What if you want to mirror queues in a cluster of queue managers? My knowledge of clustering is poor, but I could imaging that if a message is put, it is presented to the cluster which decides to which queue on what queue manager we can currently write the message.
Could mirrorq be easily set-up in such a scenario? I am asking this question as I think we will need this one day too.
Thanks in advance! |
|
Back to top |
|
 |
DAS |
Posted: Mon Dec 26, 2005 7:53 am Post subject: |
|
|
Apprentice
Joined: 15 Aug 2005 Posts: 30
|
To my despair I noticed some MirrorQ behaviour that I don't like.
I know now, that the MirrorQ Exit must be installed onto the queuemanager that holds the queue where the PUT is done, be it a remote or a local queue.
Let's give an example:
I have two queuemanagers on my system, QM1 and QM2.
On QM1 I have a REMOTE queue definition QUEUE that points to the local queue QUEUE on QM2.
Now I have the MirrorQ exit installed on QM2 and I want it to mirror messages from the local queue QUEUE to the target queue (also a local queue on QM2) LOG. My namelist data: QUEUE,LOG,QM2
All fine and all. Now when I put a message onto QUEUE using QM2 the message is mirrored. Though, when I put the message on the remote queue definition QUEUE using QM1, the message does arrive on QUEUE on QM2, though it is NOT mirrored by MirrorQ.
I find this strange, as I thought the MCA at the other end of the channel puts the message onto QUEUE on QM2 when I am using a remote put (via remote queue QUEUE on QM1), so the MirrorQ exit SHOULD be triggered on the put, or am I making a mistake here?
I do remember this part:
clindsey wrote: |
If you want to mirror messages that arrive on QLOCAL at QMGRB, then you set up mirrorq on QMGRB with the source queue as LOCALQ and the target as some other local queue on QMGRB. The messages are mirrored if the application is local, but also if the application is on QMGRA and it puts to QRemote |
So it should be possible right?
Now when I am running the mirrorq exit on QM1, using the remote queue QUEUE as a queue to mirror, everything works out fine. So I am sure that the MIRRORQ_NO_INTERNAL is not set (otherwise this put would not be mirrored would it? As the MCA is an internal MQ application?)
Help on this problem would be sincerely appreciated. |
|
Back to top |
|
 |
clindsey |
Posted: Tue Dec 27, 2005 6:52 am Post subject: |
|
|
Knight
Joined: 12 Jul 2002 Posts: 586 Location: Dallas, Tx
|
Quote: |
What if you want to mirror queues in a cluster of queue managers? My knowledge of clustering is poor, but I could imaging that if a message is put, it is presented to the cluster which decides to which queue on what queue manager we can currently write the message.
Could mirrorq be easily set-up in such a scenario? I am asking this question as I think we will need this one day too.
|
There is nothing special done for clustering. I do not know of a way you could manage this from the qmgr where the messages originate, but it should work fine if you set up mirroring on each of the cluster queues on the target qmgrs.
Charlie |
|
Back to top |
|
 |
fjb_saper |
Posted: Tue Dec 27, 2005 7:52 am Post subject: |
|
|
 Grand High Poobah
Joined: 18 Nov 2003 Posts: 20756 Location: LI,NY
|
Charlie,
This looks more and more like a COA/COD scenario with a twist monitoring channel health and xmitq depth.
What do you think ? |
|
Back to top |
|
 |
clindsey |
Posted: Tue Dec 27, 2005 7:55 am Post subject: |
|
|
Knight
Joined: 12 Jul 2002 Posts: 586 Location: Dallas, Tx
|
Quote: |
I find this strange, as I thought the MCA at the other end of the channel puts the message onto QUEUE on QM2 when I am using a remote put (via remote queue QUEUE on QM1), so the MirrorQ exit SHOULD be triggered on the put, or am I making a mistake here?
|
This worked fine for me. One thing to know is that you have to stop and start the channel so the MCA can read the new namelist.
Charlie |
|
Back to top |
|
 |
DAS |
Posted: Tue Dec 27, 2005 1:04 pm Post subject: |
|
|
Apprentice
Joined: 15 Aug 2005 Posts: 30
|
I have already started and stopped both queuemanagers, but still...no result.
The strange thing:
By looking at the API Exit logs (I set the MIRRORQ_LOG_OPTIONS to 7 and MIRRORQ_LOG_PATH to a valid directory) I can see that the API exit is not even triggered at all when putting a message on the remote queue of the other queuemanager (QM1). Only when I put a message directly onto the local queue of the queuemanager the API exit is configured for, I can see the API exit being invoked. Of course only at that time the MQ_CONNECT_AFTER is invoked.
I really find it strange that it does work for you, as apart from the namelist, the API exit should be invoke somehow, or am I mistaken?
Well, I will tinker around a bit with it some more, but could you perhaps give me some advice on how to setup things? I did the following:
- Create QM1
- Create QM2
- Create namelist in QM2
- Configure API exit for QM2
- Create appropriated queues on QM1
- Create appropriate queues on QM2
- Create sender channel on QM1
- Create receiver channel on QM2
- Stop QM1
- Stop QM2
- Start QM1
- Start QM2
As for the clustering part: ok, thanks...I thought that it would indeed be as simple as that. |
|
Back to top |
|
 |
clindsey |
Posted: Tue Dec 27, 2005 6:48 pm Post subject: |
|
|
Knight
Joined: 12 Jul 2002 Posts: 586 Location: Dallas, Tx
|
Your setup sounds good, and if you can put to the queue locally from qm2 and mirroring works, then it is all set up properly on qm2.
When you initiate the put from qm1, process amqrmppa on qm2 does the put to the local queue on qm2. mirrorq logging never writes anything for this process and I do not know why. However, an mq trace will show the api calls for amqrmppa. You will see the apiexit calls before and after every api call too. An mq trace will show you if the exit is loaded and the return code from each of the api calls.
If both qmgrs are on the same machine, start qm1, then start trace (strmqtrc -t detail -t all) and then start qm2. Now put the message from the remote qmgr and then stop trace with endmqtrc.
Use grep or find to see which trc file is for amqrmppa. Hopefully this will show you the problem. You will see the exit load. Here is the entry from my trace
Code: |
0008BBEE 20:36:43.670523 844.2 Name:"MirrorQ" Function:"EntryPoint" Module:"C:\mqm\Exits\mirrorq.dll" Data:"mirrorq"
0008BBEF 20:36:43.670529 844.2 --------{ xcsLoadFunction
0008BBF0 20:36:43.670534 844.2 Object:C:\mqm\Exits\mirrorq.dll
0008BBF1 20:36:43.671170 844.2 FullPathObj:C:\mqm\Exits\mirrorq.dll
0008BBF2 20:36:43.671180 844.2 --------} xcsLoadFunction (rc=OK)
0008BBF3 20:36:43.671186 844.2 --------{ xcsQueryProcAddr
0008BBF4 20:36:43.671192 844.2 --------} xcsQueryProcAddr (rc=OK)
|
When the exit is loaded following ConnAfter, you can see the MQOPEN and MQINQ calls for loading the namelist. And later on you should see the MQPUT of the message to your mirrored queue in the PutAfter section.
Feel free to send me your *.trc files if you want me to take a look.
Charlie |
|
Back to top |
|
 |
clindsey |
Posted: Tue Dec 27, 2005 7:03 pm Post subject: |
|
|
Knight
Joined: 12 Jul 2002 Posts: 586 Location: Dallas, Tx
|
Quote: |
This looks more and more like a COA/COD scenario with a twist monitoring channel health and xmitq depth.
|
fjb_saper, I agree it is sounding that way. |
|
Back to top |
|
 |
DAS |
Posted: Wed Dec 28, 2005 3:57 am Post subject: |
|
|
Apprentice
Joined: 15 Aug 2005 Posts: 30
|
Thanks Charlie, I will try that one out. Just to be certain, I will remove my whole configuration and rebuilt it completely. If I am still having trouble after diagnosing the traces, I will mail you the .trc files.
Thanks for your help!
EDITED 28-12-2005 AT 17:23 (GMT +1):
I think something went wrong in my configuration. After creating the whole configuration from scratch, the problem was gone. Great, but still a little bit strange
Well, good to know that this isn't a problem anymore. |
|
Back to top |
|
 |
ewilliams |
Posted: Wed Dec 28, 2005 2:08 pm Post subject: |
|
|
 Apprentice
Joined: 27 Nov 2002 Posts: 30 Location: Portland
|
Any chance of getting the lastest findings in a build? I am running into a similar problem with the indentity context issue. |
|
Back to top |
|
 |
clindsey |
Posted: Wed Dec 28, 2005 4:45 pm Post subject: |
|
|
Knight
Joined: 12 Jul 2002 Posts: 586 Location: Dallas, Tx
|
Quote: |
Any chance of getting the lastest findings in a build? I am running into a similar problem with the indentity context issue.
|
ewilliams, which o/s? |
|
Back to top |
|
 |
ewilliams |
Posted: Wed Dec 28, 2005 6:38 pm Post subject: |
|
|
 Apprentice
Joined: 27 Nov 2002 Posts: 30 Location: Portland
|
clindsey wrote: |
Quote: |
Any chance of getting the lastest findings in a build? I am running into a similar problem with the indentity context issue.
|
ewilliams, which o/s? |
Sorry about that - Windows and Sun Solaris. |
|
Back to top |
|
 |
|