| Author |
Message
|
| gechu |
 Posted: Tue Jul 19, 2011 7:14 am Post subject: poor design - scheduled tasks |
 |
|
Apprentice
Joined: 27 Feb 2008
Posts: 48
|
Hi all!
My problem is simple, I want to my message flow to get executed once a day at a certain time. My plan B is using a cron-job, but if I can keep all parts in the broker runtime it gets easier to administrate. Well, back to plan A.
I´ve read this guide about Timernodes in broker V6 http://www.ibm.com/developerworks/websphere/library/techarticles/0603_schutz/0603_schutz.html but the only configuration I´ve come up with yet to solve my "simple" problem is to use a TimeoutNotification node in "automatic mode" to trigger the message flow, which later contains ESQL code for programatically creating a TimeoutControl message which looks like this:
| Code: |
SET OutputRoot.Properties.MessageDomain = 'XMLNSC';
SET OutputRoot.MQMD.Format = MQFMT_STRING;
SET OutputRoot.XMLNSC.TimeoutRequest = InputLocalEnvironment.TimeoutRequest;
set OutputLocalEnvironment.XMLNSC.TimeoutRequest.StartTime = '11:01:01';
set OutputLocalEnvironment.XMLNSC.TimeoutRequest.StartDate = 'TODAY';
set OutputLocalEnvironment.XMLNSC.TimeoutRequest.Count = -1;
set OutputLocalEnvironment.XMLNSC.TimeoutRequest.Interval = 86400; --(24 hours)
set OutputLocalEnvironment.XMLNSC.TimeoutRequest.AllowOverwrite = TRUE; |
And finally the message created by the code above reaches a TimeoutControl node , which is associated with another TimeoutNotification node set up in controlled mode.
In short: TimeoutNotification(automatic) > build control message (ESQL) > TimeoutControl > TimeoutNotification(manual) > trailing processing...
Since I can´t tell my initial TimeoutNotification node to only send one message, I have to specify a timer interval, which is too bad since I´ll only need one message. The interval will cause multiple invocations that will result in multiple TimeoutControl messages. This is not a big problem because all control message will look the same, but it´s just ugly.
QUESTIONS:
1. Is there any better way using built in nodes to solve this problem?
2. It is likely that I´ll need to set the interval to 172800 seconds (48 hours). How does the broker handle such large interval? Performance implications? |
|
| Back to top |
|
 |
| lancelotlinc |
| Posted: Tue Jul 19, 2011 8:40 am Post subject: |
|
|
Jedi Knight
Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA
|
WMB is not a system administration engine. WMB is a high speed messaging engine. Use Cron to start the ignition.
Unless, of course, a politician designed the Mars rover.
_________________
http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER |
|
| Back to top |
|
|
| gechu |
| Posted: Tue Jul 19, 2011 10:14 pm Post subject: |
|
|
Apprentice
Joined: 27 Feb 2008
Posts: 48
|
| Thanks for your comment lancelotlinc, I´ll change change to cron-jobs. |
|
| Back to top |
|
|
| Santosh_Ghalsasi |
| Posted: Fri Nov 25, 2011 1:34 am Post subject: |
|
|
Novice
Joined: 01 Feb 2011
Posts: 19
|
I am also working on the same requirement.
I want to clarify one point -
If we use one SHARED variable called 'FLAG' and change it once the message it sent to TimeoutControl node, then will this be useful?
Means something like below.
DECLARE FLAG SHARED BOOLEAN FALSE;
-- In the code of compute node before timeoutcontrol node
IF FLAG = FALSE THEN
-- Code for Timeoutrequest parameters setting
SET OutputLocalEnvironment.TimeoutRequest.Action='SET';
SET OutputLocalEnvironment.TimeoutRequest.Identifier='Unique';
SET OutputLocalEnvironment.TimeoutRequest.StartDate= 'TODAY';
SET OutputLocalEnvironment.TimeoutRequest.StartTime= '16:37:00';
SET OutputLocalEnvironment.TimeoutRequest.Count=-1;
SET FLAG = TRUE;
RETURN TRUE;
ELSE
-- drop the the request message here
RETURN FALSE;
END IF;
Assumption -
This will make the timeoutcontrol node work only once and the notifications will get created everyday on specified time.
Please reply |
|
| Back to top |
|
|
| smdavies99 |
| Posted: Fri Nov 25, 2011 1:59 am Post subject: |
|
|
Jedi Council
Joined: 10 Feb 2003
Posts: 6076
Location: Somewhere over the Rainbow this side of Never-never land.
|
And what to shared variables happens in
- The Execution group Abends
- The execution Group is reloaded
- The broker is restarted.
Even if it all works under all conditiions perfectly, you are really adding some complexity to a Flow that is not really needed.
Use CRON. It is far simpler.
What will you need to do if you want to change the time of day the flow wakes up?
running
Is just Unix/Linux SOP.
_________________
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 |
|
|
| Santosh_Ghalsasi |
| Posted: Fri Nov 25, 2011 5:05 am Post subject: |
|
|
Novice
Joined: 01 Feb 2011
Posts: 19
|
Hi,
I tried the scenario that I have given below and it works. Just that when you give Count = -1 you must specify the interval also.
Means the code will be like below now.
DECLARE FLAG SHARED BOOLEAN FALSE;
-- Below is the code of compute node before timeoutcontrol node
IF FLAG = FALSE THEN
-- Code for Timeoutrequest parameters setting
SET OutputLocalEnvironment.TimeoutRequest.Action='SET';
SET OutputLocalEnvironment.TimeoutRequest.Identifier='Unique';
SET OutputLocalEnvironment.TimeoutRequest.StartDate= 'TODAY';
SET OutputLocalEnvironment.TimeoutRequest.StartTime= '16:37:00';
SET OutputLocalEnvironment.TimeoutRequest.Count=-1;
SET OutputLocalEnvironment.TimeoutRequest.Interval='60';
SET FLAG = TRUE;
RETURN TRUE;
ELSE
-- drop the the request message here
RETURN FALSE;
END IF;
This will cause execution of timeoutcontrol node only once and then after every 1 minute the notification will get generated. You can give the interval value as per your requirement.
Disadvantage of this is there will be a non expiring request message that will lie in - SYSTEM.BROKER.TIMEOUT.QUEUE(as I have used default queue settings) and that will never get clear. So if you want to stop the notifications then you have to manually clear it.
One more option is to make the code in such a way that the timeoutcontrol node will be executed only once in a day(when first message for file writing will arrive). But this approach will have dependency on the Message coming into flow. I have tried this approach also.
Please suggest me which approach to use.
Thanks |
|
| Back to top |
|
|
| Vitor |
| Posted: Mon Nov 28, 2011 5:29 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| Santosh_Ghalsasi wrote: |
Please suggest me which approach to use.
|
cron
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| McueMart |
| Posted: Tue Nov 29, 2011 2:46 am Post subject: |
|
|
Chevalier
Joined: 29 Nov 2011
Posts: 490
Location: UK...somewhere
|
As per : (See next post for Link - cant post URLs on your first post...) , The TimeoutInterval can be a positive Integer.
This seems to suggest that you could set up the first Automatic TimeoutNotification node with a very large TimeoutInterval (e.g. 999999999) , meaning it would be invoked when the flow is deployed.... and then not for approximately 32 years.
Does this not solve the problem of making the initial TimeoutNotification only send a single message?
Internally, I expect Broker will have a thread sleeping for a very long time (waiting on the 999999999 seconds to expire..), but this performance impact would be nothing.
I am working on a project where we are using this pattern. We needed the capability for a flow to run every 5 seconds, and to reinvoke itself at the end (as the actual processing could take some time - and we did not want 2 running concurrently; so automatic TimeoutNotification set to 5 seconds wasn't appropriate). As I see it, this method is less of an admin/config headache than using cron jobs to kick off the flow.
I welcome someone to tell me why this is wrong! Cheers. |
|
| Back to top |
|
|
| McueMart |
| Posted: Tue Nov 29, 2011 2:48 am Post subject: |
|
|
Chevalier
Joined: 29 Nov 2011
Posts: 490
Location: UK...somewhere
|
|
| Back to top |
|
|
| Vitor |
| Posted: Tue Nov 29, 2011 5:43 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| McueMart wrote: |
| I welcome someone to tell me why this is wrong! |
Please see the comments of @smdavies99 above for starters.
I'd also like to ask when cron became an admin headache.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| McueMart |
| Posted: Tue Nov 29, 2011 6:01 am Post subject: |
|
|
Chevalier
Joined: 29 Nov 2011
Posts: 490
Location: UK...somewhere
|
| Quote: |
| Please see the comments of @smdavies99 above for starters. |
Not quite sure which bit you are referring to. if its regarding the EG restarting - I dont see how using my approach causes any issues.
Regarding cron being an admin headache:
Well i agree cron isnt rocket science but how exactly do you reliably set up a cron job to run 'right after I deploy my flow or my EG restarts'? Thats the requirement in my usecase outlined in my previous post.
If I wanted a flow to be executed at exactly X time, or every 1 minute from 12:00:00 to 12:30:00 then sure , use cron...
[/quote] |
|
| Back to top |
|
|
| lancelotlinc |
| Posted: Tue Nov 29, 2011 6:30 am Post subject: |
|
|
Jedi Knight
Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA
|
| McueMart wrote: |
| Quote: |
| Please see the comments of @smdavies99 above for starters. |
Not quite sure which bit you are referring to. if its regarding the EG restarting - I dont see how using my approach causes any issues.
Regarding cron being an admin headache:
Well i agree cron isnt rocket science but how exactly do you reliably set up a cron job to run 'right after I deploy my flow or my EG restarts'? Thats the requirement in my usecase outlined in my previous post.
If I wanted a flow to be executed at exactly X time, or every 1 minute from 12:00:00 to 12:30:00 then sure , use cron...
|
[/quote]
I guess you will learn the hard way why all these people are telling you the same story...
_________________
http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER |
|
| Back to top |
|
|
| McueMart |
| Posted: Tue Nov 29, 2011 7:10 am Post subject: |
|
|
Chevalier
Joined: 29 Nov 2011
Posts: 490
Location: UK...somewhere
|
| Quote: |
| I guess you will learn the hard way why all these people are telling you the same story... |
I would prefer to have it explained to me in a well reasoned and articulated post here by an experienced practitioner regarding why what I propose wouldn't work.... Else i'll have to stick to learning it the hard way i suppose  |
|
| Back to top |
|
|
| lancelotlinc |
| Posted: Tue Nov 29, 2011 7:14 am Post subject: |
|
|
Jedi Knight
Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA
|
Vitor, Davies and myself have been using WMB for decades. We are well versed.
The exercise is simple. If you remember your high school days Computer Science class, your instructor would have told you about "separation of concerns".
| Quote: |
| In computer science, separation of concerns (SoC) is the process of separating a computer program into distinct features that overlap in functionality as little as possible. A concern is any piece of interest or focus in a program. Typically, concerns are synonymous with features or behaviors. Progress towards SoC is traditionally achieved through modularity of programming and encapsulation (or "transparency" of operation), with the help of information hiding. Layered designs in information systems are also often based on separation of concerns (e.g., presentation layer, business logic layer, data access layer, database layer). |
WMB's purpose in life is to route and transform messages. It is not designed as a system administration interface. For system administration, IBM provides Tivoli.
_________________
http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER |
|
| Back to top |
|
|
| McueMart |
| Posted: Tue Nov 29, 2011 7:23 am Post subject: |
|
|
Chevalier
Joined: 29 Nov 2011
Posts: 490
Location: UK...somewhere
|
I agree with what you say regarding separation of concerns.
...But my aim in this thread was not to discuss how to produce some ad-hoc 'administration interface' for broker; It was to discuss how to kick off a message flow when it is deployed - and to ensure that it runs every X seconds with the guarantee that only one instance is ever running concurrently. Now if this functionality had been built into the TimeoutNotification node, i imaging you would promote using it... So what is the problem with using it via a simple flow which implements it? |
|
| Back to top |
|
|
|
|
