| Author |
Message
|
| smdavies99 |
 Posted: Mon Aug 16, 2010 12:34 am Post subject: CMP & Flow monitoring- Is control possible? |
 |
|
Jedi Council
Joined: 10 Feb 2003
Posts: 6076
Location: Somewhere over the Rainbow this side of Never-never land.
|
One of the potential problems of using a Message flow to process Monitoring Events (TransactionStart etc) is the danger of an admin accidentally enabling monitoring for all flows in all EG's.
This would lead to the broker emitting two events for every one the processing flow consumes. Eventually, the Queue would get full and possibly other bad things may happen.
In order to prevent this I was looking at the CMP API with a view of the flow checking the incoming message to see if it was indeed an event for itself.
If it was then the flow would automatically disable Flow monitoring for itself. This is nowt more than a bit of defensive programming really.
The solution should be applicable for both V6.1 & V7.0.0.1. We are not planning on moving Production to V7 until early 2011 (Feb/Mar)
However it seems that even with the extra CMP functionality in V7 flow monitoring is not covered while Flow Stats is.
We are really only interedted in the start/stop events hence the use of Flow Monitoring. This would leave Flow Stats as an option for detailed analysis purposes.
I'm interested if others has found this limitation in the CMP API and if they have a work-around?
Any hints from the IBM support people around this problem would be very helpful.
Or is it simply because has no one asked for this yet?
_________________
WMQ User since 1999
MQSI/WBI/WMB/'Thingy' User since 2002
Linux user since 1995
Every time you reinvent the wheel the more square it gets (anon). If in doubt think and investigate before you ask silly questions. |
|
| Back to top |
|
 |
| mqmatt |
| Posted: Mon Aug 16, 2010 4:26 am Post subject: |
|
|
Grand Master
Joined: 04 Aug 2004
Posts: 1213
Location: Hursley, UK
|
There's nothing specifically in the CMP today to control monitoring events. (Resource and performance statistics are both there, but monitoring events currently aren't).
Please raise a requirement! |
|
| Back to top |
|
|
| smdavies99 |
| Posted: Mon Aug 16, 2010 4:59 am Post subject: |
|
|
Jedi Council
Joined: 10 Feb 2003
Posts: 6076
Location: Somewhere over the Rainbow this side of Never-never land.
|
Thanks. I guessed as much. (sigh)
Oh well, it looks like the job node is the way forward.
_________________
WMQ User since 1999
MQSI/WBI/WMB/'Thingy' User since 2002
Linux user since 1995
Every time you reinvent the wheel the more square it gets (anon). If in doubt think and investigate before you ask silly questions. |
|
| Back to top |
|
|
| smdavies99 |
| Posted: Mon Aug 16, 2010 6:09 am Post subject: |
|
|
Jedi Council
Joined: 10 Feb 2003
Posts: 6076
Location: Somewhere over the Rainbow this side of Never-never land.
|
Well, the job node support pack has one flaw. (or maybe it is in Broker...)
You can't successfully execute a :-
| Code: |
mqsichangeflowmonitoring MYBROKER -e EG_0 -f My_Monitoring_Flow -c inactive
|
command from inside the flow. i.e. you can't control yourself. The change times out.
You can control another flow using this command.
Oh well. I guess because of this failure and/or feature that we will have to consider running this in another broker. One that only has this flow deployed.(on the same physical machine though)
I can see the merits of not allowing this type of thing though. 
_________________
WMQ User since 1999
MQSI/WBI/WMB/'Thingy' User since 2002
Linux user since 1995
Every time you reinvent the wheel the more square it gets (anon). If in doubt think and investigate before you ask silly questions. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Mon Aug 16, 2010 6:14 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
I'd be surprised if the mqsichangeflowmonitoring command could tell that it was being executed from the job node from within a specific flow...
?
However, thinking again, if the flow is in an 'active but waiting' state, i.e. the job node is running and waiting for the command to complete, then it seems reasonable that the change command will not complete until the flow is inactive long enough to accept the change...
Similarly if one tried to run mqsideploy from inside a flow and asked it to redeploy the same flow... |
|
| Back to top |
|
|
| smdavies99 |
| Posted: Mon Aug 16, 2010 7:00 am Post subject: |
|
|
Jedi Council
Joined: 10 Feb 2003
Posts: 6076
Location: Somewhere over the Rainbow this side of Never-never land.
|
Ok, here are the results of some experimentation
| Code: |
DECLARE MQSI_Command CHARACTER;
SET MQSI_Command = 'cmd /c mqsichangeflowmonitoring '||
BrokerName ||
' -e ' || ExecutionGroupLabel ||' -f ' ||
'WBI_Monitoring_Statistics_Processor'
|| ' -c inactive';
SET OutputRoot.XML.message.command=MQSI_Command;
|
This give the result...
| Code: |
<message>
<Result command="cmd /c mqsichangeflowmonitoring MYBKR -e EG_1 -f ......WBI_Monitoring_Statistics_Processor -c inactive">
<JobType>COMMANDLINE</JobType>
<output>BIP8071I: Successful command completion. .</output>
<error></error>
</Result>
</message>
|
If the flow is change to itself...
| Code: |
DECLARE MQSI_Command CHARACTER;
SET MQSI_Command = 'cmd /c mqsichangeflowmonitoring '||
BrokerName ||
' -e ' || ExecutionGroupLabel ||' -f ' ||
MessageFlowLabel
--'WBI_Monitoring_Statistics_Processor'
|| ' -c inactive';
SET OutputRoot.XML.message.command=MQSI_Command;
|
Here is the reply...
| Code: |
<message>
<Result command="cmd /c mqsichangeflowmonitoring MYBKR -e EG_1 -f JOBS -c inactive">
<JobType>COMMANDLINE</JobType>
<output>BIP2087E: Broker MYBKR was unable to process the internal configuration message. .The entire internal configuration message failed to be processed successfully. .Use the messages following this message to determine the reasons for the failure. If the problem cannot be resolved after reviewing these messages, contact your IBM Support center. Enabling service trace may help determine the cause of the failure. .BIP4041E: Execution group 'EG_1' received an invalid configuration message. See the following messages for details of the error. .The message broker received an invalid configuration message and has not updated its configuration. This can arise as a result of errors in the specification of either message flows or message sets which the configuration manager was unable to detect. It can also result from a message flow requiring a type of node that is not supported by the broker installation, from the broker having become out of step with the configuration database or from other applications sending extraneous messages to the broker's configuration queues (SYSTEM.BROKER.ADMIN.QUEUE & SYSTEM.BROKER.EXECUTIONGROUP.QUEUE). .Check the relevant message flow and message set definitions, check that all necessary user-defined extensions are installed, perform a complete redeploy of the broker's configuration and ensure that no applications are writing to the broker's configuration queues. .BIP2242E: Message flow 'JOBS' could not be reconfigured because it remained busy for longer than the timeout period of '300000' .A request to reconfigure the message flow 'JOBS' was received but this could not be processed because it remained busy processing a message for longer than the timeout specified. .This can be caused by the timeout being too short considering the complexity of the flow and the size of the messages being processed. In such cases the timeout should be increased. It can also be caused by message flows containing infinite loops. In such cases the SQL should be corrected. ..BIP8036E: Negative response received. .This command sends an internal configuration message to the broker, the response received indicated that the internal configuration message was unsuccessful. .Check that the WebSphere MQ transport is available. Check the system log for further information. .</output>
<error></error>
</Result>
</message>
|
Perhaps you can't change this from within the same thread or while a thread is running. Whatever it is has quoshed my ideas in this area.
_________________
WMQ User since 1999
MQSI/WBI/WMB/'Thingy' User since 2002
Linux user since 1995
Every time you reinvent the wheel the more square it gets (anon). If in doubt think and investigate before you ask silly questions. |
|
| Back to top |
|
|
| mgk |
| Posted: Mon Aug 16, 2010 7:15 am Post subject: |
|
|
Padawan
Joined: 31 Jul 2003
Posts: 1642
|
The problem is that some commands effectively issue a stop for the flow before executing the command and then restarting it. But before a flow can be stopped all threads in it must also be stopped. And in this case your command is running on one of those threads and it is waiting for the reply from the command it sent to tell itself to stop  . The only way for this to work would be to issue the command Async' and not wait for the reply in the same flow. That is, send to message to another flow "a simple jobs flow" that then issued the command on behalf of the asking flow. And made sure that it was never asked to run a command against itself
Hope this helps,
Kind Regards,
_________________
MGK
The postings I make on this site are my own and don't necessarily represent IBM's positions, strategies or opinions. |
|
| Back to top |
|
|
| smdavies99 |
| Posted: Mon Aug 16, 2010 7:25 am Post subject: |
|
|
Jedi Council
Joined: 10 Feb 2003
Posts: 6076
Location: Somewhere over the Rainbow this side of Never-never land.
|
| mgk wrote: |
The only way for this to work would be to issue the command Async' and not wait for the reply in the same flow. That is, send to message to another flow "a simple jobs flow" that then issued the command on behalf of the asking flow. And made sure that it was never asked to run a command against itself
|
Yep, that is my guess at what it does under the hood. Sigh. Oh well.
I'm still dithering about setting up another broker to handle the events from the four production nodes. IT would be nice but gettin it approved is another matter.
_________________
WMQ User since 1999
MQSI/WBI/WMB/'Thingy' User since 2002
Linux user since 1995
Every time you reinvent the wheel the more square it gets (anon). If in doubt think and investigate before you ask silly questions. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Mon Aug 16, 2010 8:59 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| mgk wrote: |
| The only way for this to work would be to issue the command Async' and not wait for the reply in the same flow. |
Or change the job node to run a script that runs a script in the background that waits ten seconds and then issues the command.
I.e. change the job node to NOT wait for the actual command to complete. |
|
| Back to top |
|
|
| smdavies99 |
| Posted: Mon Aug 16, 2010 9:10 am Post subject: |
|
|
Jedi Council
Joined: 10 Feb 2003
Posts: 6076
Location: Somewhere over the Rainbow this side of Never-never land.
|
Then to be absolutely clean, I'd have to put some logic in the flow to stop it from being run more than once at a time.
Yes, I do know that in my case, the likleyhood of the sequence of events that would cause this bit of code to execute is pretty rare but these are the sort of things that do happen and when they do, there is usually a lot of head scratching while you figure it out.
As suggested, I have put the monitoring reset into a script that will also send a message to all logged on users (this is a Unix box) and put a number of messages in the system event log.
_________________
WMQ User since 1999
MQSI/WBI/WMB/'Thingy' User since 2002
Linux user since 1995
Every time you reinvent the wheel the more square it gets (anon). If in doubt think and investigate before you ask silly questions. |
|
| Back to top |
|
|
| prabhu_s1177 |
| Posted: Fri Jan 17, 2014 2:35 am Post subject: CMP & Flow monitoring- Is control possible? |
|
|
Apprentice
Joined: 26 Nov 2007
Posts: 34
|
Hi,
Please let me know how is this work?. Kindly share some document if any
DECLARE MQSI_Command CHARACTER;
SET MQSI_Command = 'cmd /c mqsichangeflowmonitoring '||
BrokerName ||
' -e ' || ExecutionGroupLabel ||' -f ' ||
'WBI_Monitoring_Statistics_Processor'
|| ' -c inactive';
SET OutputRoot.XML.message.command=MQSI_Command;
Where will the results will be stored and and how to see the results.
we are experimentation the above in a ESQL code. |
|
| Back to top |
|
|
| Esa |
| Posted: Fri Jan 17, 2014 3:09 am Post subject: |
|
|
Grand Master
Joined: 22 May 2008
Posts: 1387
Location: Finland
|
prabhu_s1177,
This topic is over four years old!
First of all, CMP API supports assigning monitoring profiles to flows, now. You don't need to run a command for that.
Secondly, the problem of a flow trying to administer itself still persists.
But I guess the OP solved the problem by making the flow send an MQ request to another flow that would do the job.... |
|
| Back to top |
|
|
| smdavies99 |
| Posted: Fri Jan 17, 2014 3:34 am Post subject: |
|
|
Jedi Council
Joined: 10 Feb 2003
Posts: 6076
Location: Somewhere over the Rainbow this side of Never-never land.
|
I solved the problem by detecting the first event that related to itself and then using the job node to execute a script that would switch off monitoring for the monitoring flow. Then it would ignore any subsequent messages relating to itself for the next minute.
You have to call and external script because just executing the command fails because you can't do it on the same process ID as being called from. A Unix shell script creates a new PID and all is well.
I suppose executing it from another flow in another EG might work.
What we do now (different company) is to pipe the event messages to another broker via an MQ Channel. This other broker does not have monitoring enabled. Thus you can't get monitoring events for yourself.
Naturally if some Admin decided to enable it for the monitoring broker then I'd probably get them fired on the spot because they have had training on the matter and know that this is a big No-No.
_________________
WMQ User since 1999
MQSI/WBI/WMB/'Thingy' User since 2002
Linux user since 1995
Every time you reinvent the wheel the more square it gets (anon). If in doubt think and investigate before you ask silly questions. |
|
| Back to top |
|
|
| Esa |
| Posted: Sat Jan 18, 2014 2:02 am Post subject: |
|
|
Grand Master
Joined: 22 May 2008
Posts: 1387
Location: Finland
|
@smdavies99: I would like to know if you selected to stop the event processing message flow because you encountered problems with the more simple approach of sending a pcf that would get inhibit the input queue? If you did, what kind of problems?
The problem of somebody accidentally applying a common monitoring profile to the event processing flow could easily be avoided by using non-standard node names in the flow.
The other way of enabling monitoring, overriding the bar file to enable monitoring on nodes is not something that can happen by accident, I suppose. Unless your automated deployment process always does to all flows, of course... |
|
| Back to top |
|
|
| smdavies99 |
| Posted: Sat Jan 18, 2014 2:31 am Post subject: |
|
|
Jedi Council
Joined: 10 Feb 2003
Posts: 6076
Location: Somewhere over the Rainbow this side of Never-never land.
|
I didn't stop the event monitoring flow, I just disabled the monitoring for itself.
I went to all this trouble simply to avoid problems if an admin did made a change using the -g -j switches. I call this defensive programming or my fight against 'sods' law.
In the end, I had issues with the job control node so I put the monitoring into a broker of its own. The admins were instructed not to touch that broker under any circumstances apart from when doing a system reboot/restart without my approval.
_________________
WMQ User since 1999
MQSI/WBI/WMB/'Thingy' User since 2002
Linux user since 1995
Every time you reinvent the wheel the more square it gets (anon). If in doubt think and investigate before you ask silly questions. |
|
| Back to top |
|
|
|
|
