| Author |
Message
|
| rk1891 |
 Posted: Tue Dec 06, 2016 12:03 pm Post subject: Cancelling timers on a different broker instance |
 |
|
Apprentice
Joined: 12 Oct 2011
Posts: 42
|
I have a scenario where in I need to set up timers for a specific day in a month. If the downstream process that is triggered based on this timer fails, I need to retry it 2 times for next two days.
I'm going to set up those timers using TimeoutControl node and TimeoutNotification nodes for that specific day with a count of 3 and an interval of 1 day with a unique name like 'Sample_MMYYYY'
If the downstream process is successful, I'm going to send a message to cancel the timer for that month as I know the name of the timer so it won't execute the remaining counts.
I hope I'm on right way until this point.
Having said all that, Now we have two broker instances running for high availability. So the flow containing TimeoutControl node and TimeoutNotification would be running on both of the instances.
I'm not worried about the downstream process being triggered by two timers as I have a database there to rely on to ignore one of the timers.
But after the downstream process is completed, I want to cancel the timer on both brokers not just one broker. So if Broker A receives the success message, I want to cancel the timer not only on Broker A but also Broker B.
Is there anyway I can achieve that like using CMP API? We have used CMP API to start and stop flows but not able to find any documentation in stopping/starting timers. |
|
| Back to top |
|
 |
| mqjeff |
| Posted: Tue Dec 06, 2016 12:22 pm Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
http://www.ibm.com/developerworks/websphere/library/techarticles/0603_schutz/0603_schutz.html
But don't use timeout nodes for this kind of thing.
Much better to use an external scheduler.
If you really want to do this, then set up an additional MQInput node (or whatever) that hooks into the timeout control node's input terminal.
Send it the right XML message from the successful broker to cancel the event on the other broker.
Stiill, Timout nodes are not as reliable as things like cron or at or etc.
_________________
chmod -R ugo-wx / |
|
| Back to top |
|
|
| rk1891 |
| Posted: Tue Dec 06, 2016 1:17 pm Post subject: |
|
|
Apprentice
Joined: 12 Oct 2011
Posts: 42
|
Thank you, Jeff, for prompt response. I did read that article.
Couple of lines taken out from it (Of a different context and slightly tweaked) -
| Quote: |
While the cronjob works, it adds complexity to the system compared to using timer nodes. You must co-ordinate the creation of the cron job with the development of the message flows.
Using timeout nodes provides a flexible, self-contained mechanism to start a message flow. No external coordination with the broker is required beyond what is normally required to deploy a flow. |
I was thinking about Timer nodes because of some of those reasons as Cron jobs are becoming maintenance night-mare as different people (AIX server admins) deal with those where as the brokers are maintained by a different team.
I want something built-in to the application rather than using something external which we easily lose control of.
I kind of thought of about using another MQInput but we again have two Queue managers for high availability and we use CQAs generally. So I really can't control which broker receives that message unless I specifically send the message to a QL specific to the QMgr of the other broker.
So there is no way getting active timers running in an execution group using Message Broker API? |
|
| Back to top |
|
|
| timber |
| Posted: Tue Dec 06, 2016 3:36 pm Post subject: |
|
|
Grand Master
Joined: 25 Aug 2015
Posts: 1292
|
| Quote: |
| If the downstream process is successful, I'm going to send a message to cancel the timer for that month |
It may be simpler to not bother with this. Just leave both timers triggering once every day. Add some code that checks
a) whether it's the right day in the month and
b) whether the job has already been done for this month
...which you could define as two sides of the same coin.
Provided that b) can be done efficiently, nobody will mind it happening once per day on both IIB servers. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Wed Dec 07, 2016 4:37 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
Right, yes, with CQs, you have to take additional steps to make sure the message goes where it needs to.
This is easy - just set the right values in the Destination tree.
I don't know if you can work with Timer nodes int eh Broker API. If it's not documented, then it's very likely not possible.
Timber's notion of timeouts being run frequently and checking if the other Broker has processed things successfully is fine. If you trust timber with timeouts... 
It does require some method of sharing data between the two Broker's. It can also cause some difficulty if there's a failure in the timeout flow on one broker before it sets the flag. This could cause the flow to run on the other broker... and that might fail in the same place... and so on and so on and so on...
_________________
chmod -R ugo-wx / |
|
| Back to top |
|
|
| rk1891 |
| Posted: Thu Dec 08, 2016 11:36 am Post subject: |
|
|
Apprentice
Joined: 12 Oct 2011
Posts: 42
|
Forgot to mention that the downstream process would be running on application server.
Timber's option b is also in my mind as it's a matter of 4 extra timers per month but it's difficult to convince people with doing the things that are not needed.
or other option would be to have another flow running on these brokers to get the completed acknowledgement from downstream process. Then this flow would specifically send a message to each broker QMgr's QL and a different flow would take care of cancelling those timers on individual brokers - Do you guys see any downside of it? |
|
| Back to top |
|
|
| rk1891 |
| Posted: Tue Feb 07, 2017 1:23 pm Post subject: Not doing Timers in Broker |
|
|
Apprentice
Joined: 12 Oct 2011
Posts: 42
|
Just to let you know -
Decided not to use Timers in Broker as it's not possible to sync them up across two brokers.
In WAS(Websphere Application Server) at least they are all managed by single node in a cluster, so decided to use that option.
Disappointed to be not able to use Timers efficiently.
Do you know if such kind of thing available in IIB 9.0 similar to clustering in WAS?
(We are currently on WMB 8.x, haven't explored all options in IIB).
Thanks again for your time and insights! |
|
| Back to top |
|
|
| smdavies99 |
| Posted: Tue Feb 07, 2017 11:05 pm Post subject: Re: Not doing Timers in Broker |
|
|
Jedi Council
Joined: 10 Feb 2003
Posts: 6076
Location: Somewhere over the Rainbow this side of Never-never land.
|
| rk1891 wrote: |
Just to let you know -
Decided not to use Timers in Broker as it's not possible to sync them up across two brokers.
|
do you have a common Time source for your broker servers? i.e. they sync their time up to the same reliable source?
If you do then the systems that host the brokers are sync'd.
There are ways to make timers in the two brokers work together but it is not easy.
So your solution is probably the easiest to work with in the long run.
_________________
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 |
|
|
| rk1891 |
| Posted: Wed Feb 08, 2017 6:42 am Post subject: Re: Not doing Timers in Broker |
|
|
Apprentice
Joined: 12 Oct 2011
Posts: 42
|
| smdavies99 wrote: |
| rk1891 wrote: |
Just to let you know -
Decided not to use Timers in Broker as it's not possible to sync them up across two brokers.
|
do you have a common Time source for your broker servers? i.e. they sync their time up to the same reliable source?
If you do then the systems that host the brokers are sync'd.
|
What I meant is to get Timer Nodes working together across two different brokers which seems like NOT possible. As far as the times on servers itself - Of course, they are in sync as they are managed by NPT servers. |
|
| Back to top |
|
|
|
|
