| Author |
Message
|
| inderjeetdhillon |
 Posted: Wed Aug 28, 2013 7:39 am Post subject: |
 |
|
Newbie
Joined: 28 Aug 2013
Posts: 9
|
I have a doubt about using iteration instead of currentdepth.
Lets say i have a consumer which picks up messages instead of a monitor which i am trying to create, and during the iteration (i will only browse and not pick messages from the queue), some messages will be consumed by the consumer program while more and more messages will be put on the queue by the source.
in this case how will we ever get the actual queuedepth at one specific point in time.
My assumption is that the iteration will happen too quickly and the rate of putting new messages on the queue should be lower than the iteration to get it working. |
|
| Back to top |
|
 |
| Vitor |
| Posted: Wed Aug 28, 2013 7:49 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| inderjeetdhillon wrote: |
| a monitor which i am trying to create |
Why? Why not use one of the support pacs or commerical tools?
| inderjeetdhillon wrote: |
| in this case how will we ever get the actual queuedepth at one specific point in time. |
Why do you need it? Isn't it more important from a monitoring standpoint to detect a rise in depth over time than a snapshot.
Depending on why exactly you're producing this monitor, you could also consider checking enqueue/dequeue rates or the age of the oldest message.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Aug 28, 2013 7:50 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
Moved to Monitoring Section
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| inderjeetdhillon |
| Posted: Wed Aug 28, 2013 8:12 am Post subject: |
|
|
Newbie
Joined: 28 Aug 2013
Posts: 9
|
I am planning to move to camel karaf for the actual consumer and at that point i am okay with just monitoring the rise. But with the legacy system in place it will be great to have a snapshot in time.
I wrote a small code which uses the putdate for the message to see if there is any delay, but another aspect is to see how much is the queue depth at that point. So that is where the snapshot count comes into picture.
I am new to MQseries, i got to this thread researching for the correct options to use while i connect to the queue for using getCurrentDepth().
I got till this point, but not sure http://publib.boulder.ibm.com/infocenter/wmqv7/v7r0/index.jsp?topic=%2Fcom.ibm.mq.csqzax.doc%2Fmo11160_.htm
What will be the correct option to use.
Reading the above link again to see if i missed something. |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Aug 28, 2013 8:23 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
Ok, be aware that the link you quote here is not connected to what you're asking about. You've posted about getting the depth of a queue, that link talks about the queue manager generated depth events, which are 2 different things.
| inderjeetdhillon wrote: |
| Reading the above link again to see if i missed something. |
Principally you've missed the difference between a application which is inquiring on the depth of a queue (what you posted about) and an application which is responding to depth events (the link you posted).
I still don't see what value the depth has at a given point in time has.
Note that you don't need to examine the putdate of the message to detect delay. You can use a service event (described in the same section you link to) to detect that in the same way depth events show the rise & fall of the queue depth.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| gbaddeley |
| Posted: Wed Aug 28, 2013 4:13 pm Post subject: |
|
|
Jedi Knight
Joined: 25 Mar 2003
Posts: 2538
Location: Melbourne, Australia
|
| inderjeetdhillon wrote: |
| in this case how will we ever get the actual queuedepth at one specific point in time. |
You can easily get the actual queue depth at a point in time by calling MQINQ from a 'monitoring' program. But as you pointed out, this can fluctuate up and down a large amount in a short period, depending on the rate of consumption and production of messages. This raises the question of the actual need to be concerned about queue depth. Do you only want to know if the queue depth is quite large? Consider using the queue depth events feature of MQ. This can generate an event message on a system queue when the current depth goes above a percentage threshold. This is much more efficient that polling the current depth using MQINQ.
Unless you have a service time requirement for messages you don't really need to be concerned much about queue depth (as long as the maxdepth is set high enough). A great feature of MQ is asynchronous messaging. As long as the consumer app can keep up with the volume of incoming messages over a reasonable time frame, its working as designed.
_________________
Glenn |
|
| Back to top |
|
|
| inderjeetdhillon |
| Posted: Thu Aug 29, 2013 5:49 am Post subject: |
|
|
Newbie
Joined: 28 Aug 2013
Posts: 9
|
Thanks!
I did some more research and used the ms0B support pac, this is where i realised that i was only able to access the alias and not the base queue, and started getting 2035 error.
Since i am connecting to an alias hosted and managed by our client, i guess anything i try will have to work around the security issue.
overall, i think for now either i have to work with the iteration method or create some logic around the putdate.
ps: i am still learning about the queses, feel free to correct me! |
|
| Back to top |
|
|
| Vitor |
| Posted: Thu Aug 29, 2013 7:10 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| inderjeetdhillon wrote: |
| overall, i think for now either i have to work with the iteration method or create some logic around the putdate. |
Why? What do you disagree with in the earlier posts (not just mine)?
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| inderjeetdhillon |
| Posted: Fri Aug 30, 2013 4:29 am Post subject: |
|
|
Newbie
Joined: 28 Aug 2013
Posts: 9
|
The queue is not maintained by us, it is managed by the client on their side.
We access the alias queue with login information so i am not sure if i can enable the queue depth events. for eg :-
ALTER QMGR PERFMEV(ENABLED)
ALTER QLOCAL('MYQUEUE') QDEPTHHI(80) QDPHIEV(ENABLED)
To enable Queue Depth Low events on the queue MYQUEUE with a limit set at 20%, use the following MQSC commands:
ALTER QMGR PERFMEV(ENABLED)
ALTER QLOCAL('MYQUEUE') QDEPTHLO(20) QDPLOEV(ENABLED)
To enable Queue Full events on the queue MYQUEUE, use the following MQSC commands:
ALTER QMGR PERFMEV(ENABLED)
ALTER QLOCAL('MYQUEUE') QDPMAXEV(ENABLED
I wrote a single message on the queue using a browser, and used the following options for reading from the queue(read n not pick )
gmo.options = MQC.MQGMO_BROWSE_FIRST | MQC.MQGMO_NO_WAIT | MQC.MQGMO_CONVERT;
But the iteration method never ended.. it went into an infinite loop.. do you see something to which i am acting oblivious :-
queue = qm.accessQueue (mQueue, MQC.MQOO_BROWSE | MQC.MQOO_FAIL_IF_QUIESCING);
MQGetMessageOptions gmo = new MQGetMessageOptions ();
gmo.options = MQC.MQGMO_BROWSE_FIRST | MQC.MQGMO_NO_WAIT | MQC.MQGMO_CONVERT;
try
{
while(true)
{
MQMessage message = new MQMessage();
message.messageId = null;
message.correlationId = null;
queue.get (message, gmo);
depth ++;
logger.debug("reading message number : "+depth);
}
}
catch(MQException e)
{
if (e.reasonCode != 2033)
throw e;
} |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Fri Aug 30, 2013 4:37 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
Why do you want to MQGET browse messages to count them? Uncommitted messages cannot be MQGET, so your count would be off.
Why not MQINQ the current depth attribute of the queue?
I'm confused as to what end result you are after. Is it how many messages are in the queue? Or something else? 'Iterating' is how you accomplish a task, not what you are trying to accomplish. Iterating is also labor-intensive.
_________________
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 |
|
|
| Vitor |
| Posted: Fri Aug 30, 2013 5:10 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| inderjeetdhillon wrote: |
The queue is not maintained by us, it is managed by the client on their side.
We access the alias queue with login information so i am not sure if i can enable the queue depth events. |
So get them to do it for you.
| inderjeetdhillon wrote: |
| But the iteration method never ended.. it went into an infinite loop.. do you see something to which i am acting oblivious |
Yes
I echo the comments of my worthy associate; even if you fix your code it won't work under all circumstances and won't work at all if that alias queue isn't pointing to a local queue.
What is the requirement here? Note that the wrong answer is "I am required to write an application that finds the depth of the queue by browsing messages"!
What information are you trying to obtain? What circumstances are you trying to detect? What do you plan to do if you detect them?
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Fri Aug 30, 2013 5:18 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| inderjeetdhillon wrote: |
| The queue is not maintained by us, it is managed by the client on their side. |
Then how do you know they even want you to be monitoring the depth of it?
I think you need to talk to them about why you are trying to monitor the depth of a queue on their system. |
|
| Back to top |
|
|
| inderjeetdhillon |
| Posted: Fri Aug 30, 2013 5:31 am Post subject: |
|
|
Newbie
Joined: 28 Aug 2013
Posts: 9
|
I am running the consumer for the queue and have noticed that the throughput of the consumer goes down once in a while, which ends up with a backlog on the queue. I had created throughput monitors but it sends false positives when the input rate is low itself, so i am trying to create a monitor which is more reliable than the throughput monitor for the consumer app.
Do you think the following link will be helpful
http://www.mqseries.net/phpBB2/viewtopic.php?=&p=165107 |
|
| Back to top |
|
|
| Vitor |
| Posted: Fri Aug 30, 2013 5:38 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| inderjeetdhillon wrote: |
| i am trying to create a monitor which is more reliable than the throughput monitor for the consumer app. |
Well as we've said, your method is not reliable.
| inderjeetdhillon wrote: |
| Do you think the following link will be helpful |
It does describe the MQINQ facility mentioned in this thread as a better option.
In your position I'd be more interested in developing techniques to identify what causes the throughput of the consumer to drop than a monitor to identify when it happens.
It's like building a burgler alarm that can identify to the second when your house is being broken into rather than reinforcing all the doors and replacing the locks.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| inderjeetdhillon |
| Posted: Fri Aug 30, 2013 5:59 am Post subject: |
|
|
Newbie
Joined: 28 Aug 2013
Posts: 9
|
| mqjeff wrote: |
| inderjeetdhillon wrote: |
| The queue is not maintained by us, it is managed by the client on their side. |
Then how do you know they even want you to be monitoring the depth of it?
I think you need to talk to them about why you are trying to monitor the depth of a queue on their system. |
They have a very rigid policy and have refused requests in the past to allow access to us.
I am trying to create a proactive monitor, the delay in reacting creates a depth which becomes a pain to handle .. |
|
| Back to top |
|
|
|
|
