| Author |
Message
|
| vikas.bhu |
 Posted: Mon Jan 21, 2013 10:51 pm Post subject: Current q depth in esql |
 |
|
Disciple
Joined: 17 May 2009
Posts: 159
|
Hi,
I have followed all the suggession given in fourm.
even following ESQL code is giving me same queuedepth(as 3) each time
SET refRequest.StrucLength = MQCFH_STRUC_LENGTH;
SET refRequest.Version = MQCFH_CURRENT_VERSION;
SET refRequest.Command = MQCMD_INQUIRE_Q;
SET refRequest.MsgSeqNumber = 1;
SET refRequest.Control = MQCFC_LAST;
SET refRequest.Parameter[1] = MQCA_Q_NAME;
SET refRequest.Parameter[1].* = 'TEST'; SET refRequest.Parameter[2] = MQIACF_Q_ATTRS;
SET refRequest.Parameter[2].*[1] = MQIA_CURRENT_Q_DEPTH;
Any help ? |
|
| Back to top |
|
 |
| sandy vish |
| Posted: Tue Jan 22, 2013 3:39 am Post subject: |
|
|
Apprentice
Joined: 18 Nov 2012
Posts: 27
|
|
| Back to top |
|
|
| mqjeff |
| Posted: Tue Jan 22, 2013 4:17 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
Why are you trying to read the depth of a queue from a message flow?
It's a poor measure of a lot of things.
What version of Broker are you using? |
|
| Back to top |
|
|
| exerk |
| Posted: Tue Jan 22, 2013 4:17 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
QUESTION: Why are you inquiring on current queue depth? What justification can you provide for doing so?
_________________
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 |
|
|
| sandy vish |
| Posted: Tue Jan 22, 2013 4:37 am Post subject: |
|
|
Apprentice
Joined: 18 Nov 2012
Posts: 27
|
Thnx jeff,
thought of giving a try....just to understand how the PCF parameters works,but i dont understand why is it returning 3....Valid inputs plz.... |
|
| Back to top |
|
|
| mqjeff |
| Posted: Tue Jan 22, 2013 5:27 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| sandy vish wrote: |
Thnx jeff,
thought of giving a try....just to understand how the PCF parameters works,but i dont understand why is it returning 3....Valid inputs plz.... |
You don't say what the actual depth of the actual queue is.
You don't show where you are reading the PCF Response message. |
|
| Back to top |
|
|
| sandy vish |
| Posted: Tue Jan 22, 2013 5:38 am Post subject: |
|
|
Apprentice
Joined: 18 Nov 2012
Posts: 27
|
Hey jeff,
debugging the flow in toolkit and under MQPCFthe value populates as 3.Does this parameter returns the current queue depth -MQIA_CURRENT_Q_DEPTH ?
debug tree as follows
MQPCF
Type:INTEGER:1
StrucLength:INTEGER:36
Version:INTEGER:3
Command:INTEGER:13
MsgSeqNumber:INTEGER:1
Control:INTEGER:1
Parameter:INTEGER:2016
CHARACTER:TEST2
ParameterList:INTEGER:1002
INTEGER:3
what does 3 stands for?
Can i inhbit the queue using the code mentioned
| Quote: |
/*****************************
* Assembles PCF command to inhibit GET's from a queue.
*
*/
CALL CopyMessageHeaders();
/* PCF header is following the MQMD header. */
--SET OutputRoot.MQMD.Encoding = 546; -- need remember 273 is unix
SET OutputRoot.Properties.Encoding = 546;
SET OutputRoot.MQMD.MsgType = MQMT_REQUEST;
SET OutputRoot.MQMD.Format = MQFMT_ADMIN;
SET OutputRoot.MQMD.ReplyToQ = 'FINANCIAL.RESP.CONTROL';
SET OutputRoot.MQMD.MsgSeqNumber = 1;
/* Command is 'Change Queue: Inhibit GET from queue'. */
CREATE FIELD OutputRoot.MQPCF;
DECLARE refRequest REFERENCE TO OutputRoot.MQPCF;
SET refRequest.Type = MQCFT_COMMAND;
SET refRequest.StrucLength = MQCFH_STRUC_LENGTH;
SET refRequest.Version = MQCFH_CURRENT_VERSION;
SET refRequest.Command = MQCMD_CHANGE_Q;
SET refRequest.MsgSeqNumber = 1;
SET refRequest.Control = MQCFC_LAST;
/* First parameter: Queue Name. */
-- SET refRequest.Parameter[1] = MQCA_Q_NAME;
-- SET refRequest.Parameter[1].* ='QL.BRKJX01.MPTSTP.DIFMS.MS475D01.IN.JX';
SET refRequest.Parameter[1] = MQCA_Q_NAME;
SET refRequest.Parameter[1].* = 'TEST';
SET refRequest.ParameterList[1] = MQIACF_Q_ATTRS;
SET refRequest.ParameterList[1].* = MQIA_CURRENT_Q_DEPTH;
/* Second parameter: Queue Type. */
SET refRequest.Parameter[2] = MQIA_Q_TYPE;
SET refRequest.Parameter[2].* = MQQT_LOCAL;
/* Third parameter: Allow/Inhibit GET.*/
SET refRequest.Parameter[3] = MQIA_INHIBIT_GET;
SET refRequest.Parameter[3].* = MQQA_GET_INHIBITED;
set OutputRoot.BLOB.BLOB = asbitstream(OutputRoot.MQPCF);
set OutputRoot.MQPCF = null;
set OutputRoot.MQRFH2 = null;
SET OutputRoot.MQMD.Format = MQFMT_ADMIN; |
|
|
| Back to top |
|
|
| Vitor |
| Posted: Tue Jan 22, 2013 5:38 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
I suspect in both cases you're reading the type of response (3 = integer) rather than the response itself.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Tue Jan 22, 2013 5:53 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
So your flow will have an MQOutput node that will write to SYSTEM.ADMIN.CONTROL.QUEUE.
It will then have an MQGet node, or a separate MQINPUT node that will read from 'FINANCIAL.RESP.CONTROL', since that is where you have said the response message will be sent.
ESQL is not the best language to explore PCF messages with, because in general you should not use Broker to manage queue managers. And PCF messages are only used to manage queue managers...
Well. You certainly *can* use Broker to manage queue managers, but it should be an entirely isolated copy of Broker that has no connection from or access to any business level applications of any kind, and is tightly controlled from a security point of view to ensure that you haven't just opened your queue manager network wide to control by anyone.
It's much much better to buy a management tool that will solve these issues for you.
Using Java and the PCF classes that come with Java in a standalone application is a better method to explore PCF messaging than trying to do it with ESQL. Even if you don't know Java... |
|
| Back to top |
|
|
| marko.pitkanen |
| Posted: Thu Jan 24, 2013 7:35 am Post subject: |
|
|
Chevalier
Joined: 23 Jul 2008
Posts: 440
Location: Jamsa, Finland
|
Hi,
If you really have to find out some queue depths from message flow, one option to try is to use JCN and use PCFMessageAgent and PCFMessage objects.
--
Marko |
|
| Back to top |
|
|
| sebastia |
| Posted: Wed Feb 12, 2014 5:36 am Post subject: |
|
|
Grand Master
Joined: 07 Oct 2004
Posts: 1003
|
Hi, Jeff & exerk & all.
I have a very good reason to read the flow input message depth :
to decrease CLWLPRTY so the cluster workload algorithm sends me less messages.
Do you agree it is a good purpose ?
So, I shall proceed with an extension of the question :
a) what is the best way to read th input queue depth (from an administrative agent within my flow) ?
b) what is the best way to change the queue priority ? PCF ?
c) how fast will this property change propagate to input queue managers ?
THANKS ! |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Feb 12, 2014 6:03 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| sebastia wrote: |
| Do you agree it is a good purpose ? |
No.
If you apply this to all of the flows servicing the cluster queue, then when flow A drops the priority flows B & C will notice the increase in depth (because they're now getting a %age of A's traffic), drop their priority in response and you're back where you started.
I shall proceed on the assumption you'll disagree with my views and thus:
| sebastia wrote: |
| a) what is the best way to read th input queue depth (from an administrative agent within my flow) ? |
The Java method outlined above
| sebastia wrote: |
| b) what is the best way to change the queue priority ? PCF ? |
IS there another way?
| sebastia wrote: |
| c) how fast will this property change propagate to input queue managers |
The next time the cluster refreshes. I do not recommend manually refreshing the cluster to make this effective, especially when the cluster is so heavily loaded with messages you're playing with the priorities!
Depending on how many messages are in the SCTQ, i.e. have already been through the workload algorthym(l gore rhythm? the inconvenitent truth?) it may take a while for the traffic pattern to shift.
Another reason this is not a good idea. By the time the priority has been changed, a burst of traffic may already have been distributed.
How are you going to set the priority back up? Detect a zero queue depth and send a PCF message "Me! Me! Me! Want Messages!"? 
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| sebastia |
| Posted: Wed Feb 12, 2014 6:18 am Post subject: |
|
|
Grand Master
Joined: 07 Oct 2004
Posts: 1003
|
Tx, Vitor.
I've seen lots of professional flows where there is a "monitoring" flow.
It senses lots of parameteres (CPU usage, memory, etc) by its own or under central site request.
So, the point of decision is unique, so no two diferent managers of the queue priority.
Java method - looks good to me as a starting gpoint.
PCF . the same, ( )
Cluster refreshing - I dont want to mess with it, so let it be automagical.
How often does it happen ?
If a burts of load disapears when our method starts acting it means there was no such a overload.
My admin flow shall take measures every ... 5 seconds lets say.
When the queue is empty, for the 3rd sample in arow, I shall set the priority ... back to 5 again, so I can increase it and decrease it.
And CLWLPRTY = 5 means, yes, I want more messages.
Vitor : now there is NO managing of load at all.
Just static CLWLWGHT.
This one may not be the best, but a small one is better than none, IMHO
Anyway, I would like to hear your comment about this flow control.
Sebastian. |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Feb 12, 2014 7:00 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| sebastia wrote: |
| I've seen lots of professional flows where there is a "monitoring" flow. |
I use one myself in conjunction with some tools. I still think there's a measurable difference between collecting statistics (incliuding CPU, RAM & average queue depths) for capacilty planning and tuning manually, and flows trying to balance themselves. But your site, your rules.
| sebastia wrote: |
Cluster refreshing - I dont want to mess with it, so let it be automagical.
How often does it happen ? |
I want to say every 15 minutes, but I've got 90 minutes in my head for some reason. It's documented somewhere, or someone with less caffine in their system will be along in a moment.
| sebastia wrote: |
Vitor : now there is NO managing of load at all.
Just static CLWLWGHT.
This one may not be the best, but a small one is better than none, IMHO |
I'm by no means opposed to the use of CLWLPRTY; I just don't agree it should be under programatic control at the flow level. If it had to be automated, I'd put something in the cluster workload user exit than each flow. But as I said above, your site, your choice.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Wed Feb 12, 2014 7:14 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
One cheap trick with clusters...
clusters balance load across all instances of cluster receiver channels.
Nothing prevents you from having more than one cluster receiver for the same cluser on a qmgr.
CLWLPRTY is a subtler approach, but.
Also from the book of poorly thought out ideas, one could use the Job Execution node supportPac to execute runmqsc instead of having to write PCF messages. |
|
| Back to top |
|
|
|
|
