| Author |
Message
|
| Mut1ey |
 Posted: Fri Oct 23, 2009 3:52 am Post subject: MirrorQ - anybody using in production |
 |
|
Acolyte
Joined: 07 Oct 2005
Posts: 74
Location: England
|
Hi All
We are toying with the idea of using the MirrorQ API exit, and potentially placing into production.
Anybody have any experiences of using it - good or bad?
Thanks |
|
| Back to top |
|
 |
| WMBDEV1 |
| Posted: Fri Oct 23, 2009 3:53 am Post subject: |
|
|
Sentinel
Joined: 05 Mar 2009
Posts: 888
Location: UK
|
| The mirrorq app is a sampple and is not intended to be used in production environment. Do so at your own risk! |
|
| Back to top |
|
|
| Mut1ey |
| Posted: Fri Oct 23, 2009 4:26 am Post subject: |
|
|
Acolyte
Joined: 07 Oct 2005
Posts: 74
Location: England
|
| WMBDEV1 wrote: |
| The mirrorq app is a sampple and is not intended to be used in production environment. Do so at your own risk! |
Yes, I realise that and I myself am not advocating it's use. |
|
| Back to top |
|
|
| exerk |
| Posted: Fri Oct 23, 2009 5:01 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
Use the facilities within WMQ V7.0 to do it 'natively'...
_________________
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 |
|
|
| hopsala |
| Posted: Fri Oct 23, 2009 12:46 pm Post subject: |
|
|
Guardian
Joined: 24 Sep 2004
Posts: 960
|
| exerk wrote: |
| Use the facilities within WMQ V7.0 to do it 'natively'... |
Now I'm curious - is there a new V7 feature which allows message duplication? Can it duplicate messages from a queue in one QM to a queue in another? (by MQPUTing to some remoteq etc) |
|
| Back to top |
|
|
| mqjeff |
| Posted: Fri Oct 23, 2009 1:03 pm Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| hopsala wrote: |
| exerk wrote: |
| Use the facilities within WMQ V7.0 to do it 'natively'... |
Now I'm curious - is there a new V7 feature which allows message duplication? Can it duplicate messages from a queue in one QM to a queue in another? (by MQPUTing to some remoteq etc) |
Yes. It's called "pub/sub".
You define a TOPIC that acts as the destination of the sending app and two subscriptions to the "real" destination queues. |
|
| Back to top |
|
|
| jeevan |
| Posted: Fri Oct 23, 2009 2:10 pm Post subject: |
|
|
Grand Master
Joined: 12 Nov 2005
Posts: 1432
|
| mqjeff wrote: |
| hopsala wrote: |
| exerk wrote: |
| Use the facilities within WMQ V7.0 to do it 'natively'... |
Now I'm curious - is there a new V7 feature which allows message duplication? Can it duplicate messages from a queue in one QM to a queue in another? (by MQPUTing to some remoteq etc) |
Yes. It's called "pub/sub".
You define a TOPIC that acts as the destination of the sending app and two subscriptions to the "real" destination queues. |
But this is not exactly mirroring as the support pac mirrorQ does. Is it? To me mirroring from the perpective of the mirrorQ does is when a message arrive to a queue, copy it to a another queue (same queue manager or different). I have used MirrorQ for this functionality. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Fri Oct 23, 2009 3:01 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7717
|
App A is putting to a local q called Q1. App B is pulling from Q1. You have MQ 7 and want to duplicate the messages but do not want to change the sending or receiving app code.
Define a topic called Q1T, with a topic string of Q1
Define a sub to topic object Q1T, with a destination of Q1
Define a Q Alias called Q1Alias, target type topic with a target of Q1T
A put to Q1Alias will now produce a message to the Q1 local queue
Define another sub to topic object Q1T, this time with a destination of Q2
A put to Q1Alias will now produce 2 messages, one to Q1 and one to Q2.
The only change in the original setup is that App A puts to Q1Alias instead of Q1. App A and App B don't know they are using Pub Sub. The subscriptions are created by the MQ Admin using admin commands.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| John89011 |
| Posted: Fri Oct 23, 2009 3:36 pm Post subject: |
|
|
Voyager
Joined: 15 Apr 2009
Posts: 94
|
| Why don't you have the application do the duplication instead of MQM? For example what we do is, we get the request from one source, process it and send duplicate responses to two different response queues. |
|
| Back to top |
|
|
| Vitor |
| Posted: Fri Oct 23, 2009 4:12 pm Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| John89011 wrote: |
| Why don't you have the application do the duplication instead of MQM? |
Because it's an existing application for which there's no time/budget/political will to change?
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| hopsala |
| Posted: Fri Oct 23, 2009 11:52 pm Post subject: |
|
|
Guardian
Joined: 24 Sep 2004
Posts: 960
|
| PeterPotkay wrote: |
| The only change in the original setup is that App A puts to Q1Alias instead of Q1. App A and App B don't know they are using Pub Sub. The subscriptions are created by the MQ Admin using admin commands. |
Actually, you could simply change Q1 be the alias, so that no code changes are required. Thanks for the guide
MQ 7.0 rocks! |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Sat Oct 24, 2009 3:48 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7717
|
| hopsala wrote: |
| PeterPotkay wrote: |
| The only change in the original setup is that App A puts to Q1Alias instead of Q1. App A and App B don't know they are using Pub Sub. The subscriptions are created by the MQ Admin using admin commands. |
Actually, you could simply change Q1 be the alias, so that no code changes are required. Thanks for the guide
MQ 7.0 rocks! |
You could, but then the consuming apps would have to pick a new queue name for have their subscriptions go to. They wouldn't be able to MQGET against Q1 if it was an Alias to a topic.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| hopsala |
| Posted: Sat Oct 24, 2009 7:42 am Post subject: |
|
|
Guardian
Joined: 24 Sep 2004
Posts: 960
|
| PeterPotkay wrote: |
| You could, but then the consuming apps would have to pick a new queue name for have their subscriptions go to. They wouldn't be able to MQGET against Q1 if it was an Alias to a topic. |
Yeah, you're right. I spoke before I thought. It's a trade between changing either provider or consumer, but you have to change one of them. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Sat Oct 24, 2009 2:13 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20696
Location: LI,NY
|
| hopsala wrote: |
| PeterPotkay wrote: |
| You could, but then the consuming apps would have to pick a new queue name for have their subscriptions go to. They wouldn't be able to MQGET against Q1 if it was an Alias to a topic. |
Yeah, you're right. I spoke before I thought. It's a trade between changing either provider or consumer, but you have to change one of them. |
All depends on where the broker is and where the sender / receiver are.
If the sender and receiver reside on / attach to a different qmgr, you could possibly set it up so that neither have to change and all you do is change some of the underlying MQ stuff.
Have fun 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| Mut1ey |
| Posted: Sat Oct 24, 2009 3:06 pm Post subject: |
|
|
Acolyte
Joined: 07 Oct 2005
Posts: 74
Location: England
|
Actually we have broker in the mix too. Version 7 is not an option at this stage.
My preferred approach is to write a simple message flow (Wire Tap Pattern, I believe) that will stand between existing flows and the original Q. The only change to an existing Broker flow would be to re-configure its input Q so the new message "duplicator" could get messages off of the original inbound queue and forward to it. The input queues can be overridden in the bar file.
I would see the flow with one MQInput, one Compute, and two MQOutput nodes. Parsing would be BLOB and the only reason Compute is in there is to change an MQMD field value. Would not want any Failure or Catch processing as we would want the failure to cause an alert, and back out both PUTs.
This approach seems better to me because it is controlled and managed as part of the broker infrastructure, can be scaled and managed much more easily, and is much less "pervasive" than an API exit. Also, it allows for further "enhancements" down the line, should they be required, without touching the real - core business application logic.
Thoughts?
I am still interested to know if anyone is using the Mirror Q (api exit version) or a home-grown api-exit-based duplicator, in anger, and what their experiences are. After simple, small scale perf tests, we found that there is about a 20% overhead in using MirrorQ. We will be doing more extensive testing soon, but there is a feeling of general unease about this API Exit approach. It is too "embedded" and invisible. ......
Thanks |
|
| Back to top |
|
|
|
|
