ASG
IBM
Zystems
Cressida
Icon
Netflexity
 
  MQSeries.net
Search  Search       Tech Exchange      Education      Certifications      Library      Info Center      SupportPacs      LinkedIn  Search  Search                                                                   FAQ  FAQ   Usergroups  Usergroups
 
Register  ::  Log in Log in to check your private messages
 
RSS Feed - WebSphere MQ Support RSS Feed - Message Broker Support

MQSeries.net Forum Index » IBM MQ Performance Monitoring » Monitor Messages Flowing Through SVRCONN

Post new topic  Reply to topic Goto page Previous  1, 2
 Monitor Messages Flowing Through SVRCONN « View previous topic :: View next topic » 
Author Message
PeterPotkay
PostPosted: Thu May 21, 2009 12:40 am    Post subject: Reply with quote

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
View user's profile Send private message
AkankshA
PostPosted: Thu May 21, 2009 1:17 am    Post subject: Reply with quote

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
View user's profile Send private message Visit poster's website
Vitor
PostPosted: Thu May 21, 2009 1:41 am    Post subject: Reply with quote

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
View user's profile Send private message
mqjeff
PostPosted: Thu May 21, 2009 4:48 am    Post subject: Reply with quote

Grand Master

Joined: 25 Jun 2008
Posts: 17447

http://publib.boulder.ibm.com/infocenter/wmqv6/v6r0/index.jsp?topic=/com.ibm.mq.amqzag.doc/fa15730_.htm
Back to top
View user's profile Send private message
harish_td
PostPosted: Thu May 21, 2009 5:54 am    Post subject: Reply with quote

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
View user's profile Send private message Yahoo Messenger
Vitor
PostPosted: Thu May 21, 2009 6:23 am    Post subject: Reply with quote

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
View user's profile Send private message
Display posts from previous:   
Post new topic  Reply to topic Goto page Previous  1, 2 Page 2 of 2

MQSeries.net Forum Index » IBM MQ Performance Monitoring » Monitor Messages Flowing Through SVRCONN
Jump to:  



You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
Protected by Anti-Spam ACP
 
 


Theme by Dustin Baccetti
Powered by phpBB © 2001, 2002 phpBB Group

Copyright © MQSeries.net. All rights reserved.