Author |
Message
|
Api123 |
Posted: Thu Jun 03, 2010 5:09 am Post subject: |
|
|
Apprentice
Joined: 26 May 2010 Posts: 31
|
I’m looking into SUB\PUB design right now, even though I think it will complicate configuration and support later on.
Copying a messages using trigger is a simple process in Windows–couple lines of code:
1- implements the IMQObjectTrigger interface output class library “.dll”
2- Run runmqdnm loading the .dll
3- You can get fancy and run runmqdnm from a windows service (1- To hide the process, 2- monitor the process, 3- log to eventlog)
When testing no overhead was noticed. I‘ve sent (5000) messages (32k) with in range of 2-3 seconds. Messages arrived in local Q, copied to xmitq and a local queue (logging queue).
In my opinion this is quit good. The only issues with this approach is: I could be adding unnecessary layer of dependency by the trigger application been the link between queues. |
|
Back to top |
|
 |
exerk |
Posted: Thu Jun 03, 2010 5:22 am Post subject: |
|
|
 Jedi Council
Joined: 02 Nov 2006 Posts: 6339
|
And when the trigger fails? I'm with mqjeff on this one... _________________ 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 |
|
 |
Vitor |
Posted: Thu Jun 03, 2010 5:42 am Post subject: |
|
|
 Grand High Poobah
Joined: 11 Nov 2005 Posts: 26093 Location: Texas, USA
|
Api123 wrote: |
In my opinion this is quit good. |
Then go in peace and enjoy your solution as you've designed it. In the end it's your opinion that counts because it's your site and you know the particular requirements. If having asked for advice you decide the advice is inappropriate to your situation that's fine. _________________ Honesty is the best policy.
Insanity is the best defence. |
|
Back to top |
|
 |
zpat |
Posted: Thu Jun 03, 2010 5:52 am Post subject: |
|
|
 Jedi Council
Joined: 19 May 2001 Posts: 5867 Location: UK
|
|
Back to top |
|
 |
Api123 |
Posted: Thu Jun 03, 2010 6:02 am Post subject: |
|
|
Apprentice
Joined: 26 May 2010 Posts: 31
|
Vitor - Take it easy, (In my opinion this is quit good.) I was ment performance for our requirements as the backend applications are asynchronous. I value every one’s input |
|
Back to top |
|
 |
Api123 |
Posted: Thu Jun 03, 2010 6:13 am Post subject: |
|
|
Apprentice
Joined: 26 May 2010 Posts: 31
|
zpat,I've used the message multiplexer from capitalware. Great tool, in my case I needed to tap into the message while coping |
|
Back to top |
|
 |
Vitor |
Posted: Thu Jun 03, 2010 6:26 am Post subject: |
|
|
 Grand High Poobah
Joined: 11 Nov 2005 Posts: 26093 Location: Texas, USA
|
Api123 wrote: |
Vitor - Take it easy |
As many in here will tell you, I'm very easy.
My point was that whatever we say in here, you are the one to make the final decision about what you do. Eventually you'll have to plump for a solution and you should have confidence in your ability to decide.  _________________ Honesty is the best policy.
Insanity is the best defence. |
|
Back to top |
|
 |
bruce2359 |
Posted: Thu Jun 03, 2010 10:22 am Post subject: |
|
|
 Poobah
Joined: 05 Jan 2008 Posts: 9475 Location: US: west coast, almost. Otherwise, enroute.
|
exerk wrote: |
Extracted from one of PeterPotkay's posts:
Quote: |
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. |
A cheap and cheerful way of duplicating messages...and it works when a sub is a QR too. |
Agreed. The pub/sub way is quick and easy. I got this working in about 2 minutes.
For additional fun: I created a third subscription to put two copies of the same message in Q2. Then, I created another subscription to put a copy of the same msg in Q1, Q2 and Q3. The fun is endless. _________________ 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 |
|
 |
Api123 |
Posted: Thu Jun 03, 2010 10:46 am Post subject: |
|
|
Apprentice
Joined: 26 May 2010 Posts: 31
|
Agreed. PeterPotkay's posts suggestion works. I had to duplicate the configuration for the (send and receive)
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 Q2T, this time with a destination of Q2
A put to Q1Alias will now produce 2 messages, one to Q1 and one to Q2.
Q2 in my case is xmitq. |
|
Back to top |
|
 |
fjb_saper |
Posted: Thu Jun 03, 2010 12:00 pm Post subject: |
|
|
 Grand High Poobah
Joined: 18 Nov 2003 Posts: 20763 Location: LI,NY
|
Api123 wrote: |
Agreed. PeterPotkay's posts suggestion works. I had to duplicate the configuration for the (send and receive)
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 Q2T, this time with a destination of Q2
A put to Q1Alias will now produce 2 messages, one to Q1 and one to Q2.
Q2 in my case is xmitq. |
Q2 should not be the xmitq but a remote queue having the xmiq in its xmitq field.  _________________ MQ & Broker admin |
|
Back to top |
|
 |
Api123 |
Posted: Thu Jun 03, 2010 12:21 pm Post subject: |
|
|
Apprentice
Joined: 26 May 2010 Posts: 31
|
Q2 is the queue name, queue type is remote . This is how it's defined (define qlocal (Q2) usage(xmitq)) |
|
Back to top |
|
 |
bruce2359 |
Posted: Thu Jun 03, 2010 2:34 pm Post subject: |
|
|
 Poobah
Joined: 05 Jan 2008 Posts: 9475 Location: US: west coast, almost. Otherwise, enroute.
|
Quote: |
define qlocal (Q2) usage(xmitq |
This is a QLocal definition of a transmission queue, not a QRemote definition that resolves to a transmission queue. _________________ 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 |
|
 |
Api123 |
Posted: Fri Jun 04, 2010 5:11 am Post subject: |
|
|
Apprentice
Joined: 26 May 2010 Posts: 31
|
Correction: Q2 is a definition for a remote queue |
|
Back to top |
|
 |
zpat |
Posted: Fri Mar 18, 2011 4:50 am Post subject: |
|
|
 Jedi Council
Joined: 19 May 2001 Posts: 5867 Location: UK
|
I know this is pub/sub 101, but can someone share the full MQSC command for defining the subscription correctly as above? |
|
Back to top |
|
 |
bruce2359 |
Posted: Fri Mar 18, 2011 5:15 am Post subject: |
|
|
 Poobah
Joined: 05 Jan 2008 Posts: 9475 Location: US: west coast, almost. Otherwise, enroute.
|
Did you look in the MQSC manual for DEFINE SUB? _________________ 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 |
|
 |
|