| Author |
Message
|
| Yanghui |
 Posted: Tue Jan 14, 2003 3:14 am Post subject: Copy a message on a different queue |
 |
|
Disciple
Joined: 08 May 2002
Posts: 151
Location: Dublin, Ireland
|
Hi,
From day one, I have been looking for a function within MQ or MQSI. Actually the funtion is very simple. I just want to make a copy of each new message on a queue to a different queue without removing it. As far as I know, there is no utility to achieve this. I think probably it's very difficult for third party utility to do this. How is third party utility able to distinguish which message has been copied and which is new by using none-db solution?
Actually what I am expecting is a queue attribute which is like a switch. When I switch it on with a supplied queue name, then all the new coming messages on the queue will be left a copy on the provided queue as well.
Do you have any idea about this? Thanks.
-Yanghui |
|
| Back to top |
|
 |
| bower5932 |
| Posted: Tue Jan 14, 2003 5:47 am Post subject: |
|
|
Jedi Knight
Joined: 27 Aug 2001
Posts: 3023
Location: Dallas, TX, USA
|
| I believe the mirrorq in the c/C++ repository is designed to do this. You might want to look at it. |
|
| Back to top |
|
|
| XIPO |
| Posted: Tue Jan 14, 2003 7:22 am Post subject: Re: Copy a message on a different queue |
|
|
Novice
Joined: 17 Dec 2002
Posts: 13
Location: Spain
|
I don´t know if I have understood  what you are asking for, but have you try to use the trigger option?, you can launch a process for each new message that your queue receive. This process have just to browse the last message and copy it to another queue.
It´s just and idea, if this is what you want to do and you are using java, the code is easy (¿was this what you wanted?).
If it´s not, ¡good luck!  |
|
| Back to top |
|
|
| Yanghui |
| Posted: Tue Jan 14, 2003 8:30 am Post subject: |
|
|
Disciple
Joined: 08 May 2002
Posts: 151
Location: Dublin, Ireland
|
Thanks for your reponse.
To me, one problem in mirrorq is that the sending application has to change its destination q by using staging q. The whole process is not intact any more and also it increases the maintainence workload.
It seems there is no straight simple solution. The tricky part is how to copy the uncopied messages out of queue. Probably only queue manager can achieve easily and send a copy to copy queeu before sending it to destination queue. Anyway, hope IBM will include this function in.
-Yanghui |
|
| Back to top |
|
|
| RogerLacroix |
| Posted: Tue Jan 14, 2003 9:37 pm Post subject: |
|
|
Jedi Knight
Joined: 15 May 2001
Posts: 3264
Location: London, ON Canada
|
If there was a "switch" in the MQMD, you would still need to "get" the message, update the "switch" and then "put" the message back to the queue.
Therefore, I don't see any difference in using MirrorQ.
later
Roger...
_________________
Capitalware: Transforming tomorrow into today.
Connected to MQ!
Twitter |
|
| Back to top |
|
|
| dgolding |
| Posted: Tue Jan 14, 2003 11:21 pm Post subject: |
|
|
Yatiri
Joined: 16 May 2001
Posts: 668
Location: Switzerland
|
I've never actually used them, but wouldn't a distribution list do here, with the two queues ("real" and "copy") being on the list? Then there is no code, utility, function or whatever - it's done with a single operation.
My $0.02  |
|
| Back to top |
|
|
| Yanghui |
| Posted: Wed Jan 15, 2003 3:42 am Post subject: |
|
|
Disciple
Joined: 08 May 2002
Posts: 151
Location: Dublin, Ireland
|
Thanks for all the responses.
When there are many MQ apps in different envs like dev, systest, test, and production, this simple function becomes nightmare if it's designed in either MQ apps or WMQI message flow and design the mechanism of making copy of anything since you don't know when and where you will need those copies(most time, you don't). The price is too high.
I still think it would be much nicer if QManager can make a copy on different q for you when you require it. Then you don't have to make any change in any MQ app. It's really more like an admin job which shouldn't be part of regular business process or design.
Here is one scenario where the function can be very helpful. One MQ app claims a msg's sent over but one of downstream msg-consuming apps says no msg ever arriving. Channel is running and all connections are fine. Was there a msg going through? Meanwhile you have difficulty to stop QManager to read MQ log (it's not pleasent to read them either). Nobody wants to change current app setup. As far as my experience, MQ never loses msg. How can we prove there was a msg through and what was it? It can become huge headache if more than one company are involved.
-Yanghui |
|
| Back to top |
|
|
| dgolding |
| Posted: Wed Jan 15, 2003 4:09 am Post subject: |
|
|
Yatiri
Joined: 16 May 2001
Posts: 668
Location: Switzerland
|
As in my earlier post, if you do a single PUT to a distribution list (DL), and not a queue, then it will go to two or more queues at once. By using a QALIAS you could probably turn it off or on at will outside the program, I'm not 100% sure about that.
This is effect taking a copy of everything for you. Just change your code once to put to a DL, and then forget about it! Point your Alias to the target queue, or alternatively to the DL.
Details are in the Application Programming Guide - "Putting Messages to a Queue"
HTH |
|
| Back to top |
|
|
| nimconsult |
| Posted: Fri Jan 17, 2003 12:48 am Post subject: |
|
|
Master
Joined: 22 May 2002
Posts: 268
Location: NIMCONSULT - Belgium
|
The problem with distribution list is that they are not transparent to the application, they need to be defined in the code, and not in the queue manager.
It is something I would put in a MQ Series wish list, have a "distribution list" object defined in the queue manager, so that you can open this object and put messages like any other queue.
In the meantime, here are two solutions of message replication:
1) First solution is to browse the queue and copy every existing or further new incoming messages into a second queue. In fact what I propose is to run a long running "MirrorQ" utility.
I propose a sample "CopyQueue" in the JASMQ package. You should add one line of code in the sample: "s.setWaitIntervalUnlimited();", so that the "CopyQueue" utiliity becomes a long running server.
2) Second solution is to retrieve messages from the single application queue and replicate them into two queues. I propose a sample "ReplicateMessageServer" in the JASMQ package. This second option is more expensive in term of resources but supports restart without loosing or duplicating messages.
You can download the JASMQ package for free in the software repository: http://www.mqseries.net/pafiledb203/pafiledb.php?action=viewfile&fid=57
Nicolas
_________________
Nicolas Maréchal
Senior Architect - Partner
NIMCONSULT Software Architecture Services (Belgium)
http://www.nimconsult.be |
|
| Back to top |
|
|
|
|
