Author |
Message
|
PeterPotkay |
Posted: Thu May 21, 2009 12:40 am Post subject: |
|
|
 Poobah
Joined: 15 May 2001 Posts: 7722
|
PeterPotkay wrote: |
AkankshA wrote: |
... the problem increases manyfold, when we hv load...
|
Is this a JMS app doing selective gets against queues with a depth > 0? |
_________________ Peter Potkay
Keep Calm and MQ On |
|
Back to top |
|
 |
AkankshA |
Posted: Thu May 21, 2009 1:17 am Post subject: |
|
|
 Grand Master
Joined: 12 Jan 2006 Posts: 1494 Location: Singapore
|
PeterPotkay wrote: |
PeterPotkay wrote: |
AkankshA wrote: |
... the problem increases manyfold, when we hv load...
|
Is this a JMS app doing selective gets against queues with a depth > 0? |
|
No.. the receving application is WMB and picking message in FIFO order...
the env is linux... could not understand the trace message funda... are you not referring to strmqtrc here... ? _________________ Cheers |
|
Back to top |
|
 |
Vitor |
Posted: Thu May 21, 2009 1:41 am Post subject: |
|
|
 Grand High Poobah
Joined: 11 Nov 2005 Posts: 26093 Location: Texas, USA
|
AkankshA wrote: |
the env is linux... could not understand the trace message funda... are you not referring to strmqtrc here... ? |
No. We're talking about using trace messages to indicate the flow and responsivenes of your cluster. Or I am.  _________________ Honesty is the best policy.
Insanity is the best defence. |
|
Back to top |
|
 |
mqjeff |
Posted: Thu May 21, 2009 4:48 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008 Posts: 17447
|
|
Back to top |
|
 |
harish_td |
Posted: Thu May 21, 2009 5:54 am Post subject: |
|
|
Master
Joined: 13 Feb 2006 Posts: 236
|
Disclaimer: Very dirty method in comparison to all the learned posts on this thread
I once had to prove that messages are indeed arriving on my queue in an almost similar setup.
1. The putting application puts to an Alias Queue (AQ). This resolves to two target queues shared in cluster (TA and TB) --> Existing setup i assume
2. Amend the alias queue to point to a physical target queue on the local/ gateway queue manager [Not in cluster].
3. Set triggering on this new physical queue to a trigger depth of Every
4. Define a process to listen to this queue every time a trigger is set off
5. Log the message and then send this message to a new alias queue (AQ1) which load balances into TA and TB as before (I used ma01 support pac to log a message to a staging queue and then send another copy of the message to the new alias queue)
I was able to prove that even with this dirty multi-hop setup my messages were delivered faster than the MQ-doubting thomases
If you have to prove the speed of cluster resolution you can perhaps repeat the triggering on the destination queue managers by amending in the same way
I am ready to be trouted now master  |
|
Back to top |
|
 |
Vitor |
Posted: Thu May 21, 2009 6:23 am Post subject: |
|
|
 Grand High Poobah
Joined: 11 Nov 2005 Posts: 26093 Location: Texas, USA
|
harish_td wrote: |
I am ready to be trouted now master  |
Well this method does have the disadvantage that you have to put everything back the way it was when you finished; potentially a problem depending on your controls.
But you did describe it as "dirty" right up front. And it will prove the point, even if it does have a few downsides.
The Trout passes over you, and heads for the proper targets - the yo-hos who believe there's a problem with cluster resolution speed, as I've said before.
Show me the delay! Show me the delay! (to paraphrase a well known film) _________________ Honesty is the best policy.
Insanity is the best defence. |
|
Back to top |
|
 |
|