| Author |
Message
|
| sidharth_bora |
 Posted: Mon Aug 20, 2007 1:21 am Post subject: trigger type Every |
 |
|
Voyager
Joined: 24 Nov 2005
Posts: 87
|
Hi Guys,
please shed somelight on trigger type every. We are facing a very peculiar problem.
A queue in our set up is triggered for every message. for every message being put , its triggering the corresponding application, but yesterday when the message flow was on a higher rate, for one message it didnt get trigger and the message was stuck in the queue.
please advise, if we need to alter some parameter like qservice interval etc.
PS: for every successful trigger a log is written to a file
When the stuck message was again re-put to the queue theough the applicationj, it was processed successfully.
we are on MQ 5.3 CSD11
regds
Sid |
|
| Back to top |
|
 |
| Vitor |
| Posted: Mon Aug 20, 2007 1:37 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
There are very few instances where trigger EVERY is a good idea. You don't mention what platform you're on but unless you're throtteling the applications with something like CICS you can end up with a storm of applications.
Also if you code applications to read the queue until empty & use FIRST then you don't get this stuck message problem. If you're worried about throughput there are many ways you can spin up new copies of the application to deal with peak loads.
In your instance, I'd suspect that you're right & something like service interval prevented the trigger firing. You could try tuning, but I'd just redesign to avoid trigger EVERY. There are many discussions on the forum about why it's a bad idea.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| sidharth_bora |
| Posted: Mon Aug 20, 2007 5:07 pm Post subject: |
|
|
Voyager
Joined: 24 Nov 2005
Posts: 87
|
Hi Vitor, Jeff, all grandmasters, All
I need your expertise here as this is happening intermittently now. Its an application requirement that every message being put to this queue will call a map which processes the message from the queue.
Please let me know how do i tune the parameters, Presnetly all are havinf default values, and this being in PROD, I dont know how will i be able to stimulate it in DEV.
please advise
regds
Sid |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Mon Aug 20, 2007 5:16 pm Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
| Vitor wrote: |
| There are very few instances where trigger EVERY is a good idea. |
| Vitor wrote: |
| code applications to read the queue until empty & use FIRST |
"Grand Master" just means "posts a lot".
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| sidharth_bora |
| Posted: Mon Aug 20, 2007 7:10 pm Post subject: |
|
|
Voyager
Joined: 24 Nov 2005
Posts: 87
|
Hi Jeff,
Thanks for your input and time. Will liaise with the application team
regds
Sid |
|
| Back to top |
|
|
| Vitor |
| Posted: Mon Aug 20, 2007 11:13 pm Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| sidharth_bora wrote: |
| Its an application requirement that every message being put to this queue will call a map which processes the message from the queue. |
I would be amazed to discover that this requires a separate instance of the application to achieve this, and that it is the only possible application solution.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| supreeth |
| Posted: Tue Aug 21, 2007 1:40 pm Post subject: |
|
|
Voyager
Joined: 17 May 2005
Posts: 90
Location: London
|
absolutely ... trigtype first wud be a better approach ... jus check around the TRIGINT value to have an optimal value.
cheerz!!!
supreeth
_________________
Supreeth Gururaj
IBM Certified WMQ Solution Expert |
|
| Back to top |
|
|
| sidharth_bora |
| Posted: Tue Aug 21, 2007 6:47 pm Post subject: |
|
|
Voyager
Joined: 24 Nov 2005
Posts: 87
|
Hi All,
Thanks for the inputs and reply, I am still in discussion with the application team.
But I wonder, if for the good design consideration, TRIGGER EVERY shouldnt be used as then why its there ? These are the questions will be put forward by the application team before ever thinking of changing their code. Also the same application is using TRIGGER EVERY for other jobs to fire and its working quite well.
Now to the optimal setting. How do i decide ? is there any utility/bench mark etc to come to a near perfect solution
regds
Sid |
|
| Back to top |
|
|
| supreeth |
| Posted: Tue Aug 21, 2007 7:14 pm Post subject: |
|
|
Voyager
Joined: 17 May 2005
Posts: 90
Location: London
|
Well Sidharth ... deciding on the trigtype is completely driven by the application requirement. well, to be frank ... I have never come across any scenarios where my trigtype had to be every.
Bear in mind that starting a new process for every message could work out as an expensive exercise on the kernel. U may reach ur MAXPROC limit sooner rather than later. Theres no hard and fast rule however to make ur trig type as first. u can leave it the way it is. But ur issue of trigger not firing in sometimes ... can leave the messages cluttered on the queue coz I am sure u r just reading a single message and processing it from the application which gets triggered.
Also TRIGINT is applicable/effective only for TRIGTYPE FIRST i suppose ...
I am not aware of any bench mark tools ... its just being a bit careful not to set it to too low as it effectively works out as trigtype every. also not too high to nullify its purpose.
cheerz!!!
supreeth
_________________
Supreeth Gururaj
IBM Certified WMQ Solution Expert |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Aug 22, 2007 12:03 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| sidharth_bora wrote: |
| But I wonder, if for the good design consideration, TRIGGER EVERY shouldnt be used as then why its there ? |
For the same reason the product allows you to set message id. It's a very bad idea but the facility is provided to cater for every eventuality. As I said there are very few instances where trigger type EVERY is a good idea, and this does not appear to be one of them, but in case your requirement can only be satisfied by this the trigger is provided.
| sidharth_bora wrote: |
| Also the same application is using TRIGGER EVERY for other jobs to fire and its working quite well. |
Then you don't need to change it and shouldn't have started this thread! 
I think the key problems with trigger EVERY have been covered in this thread, and you've found one of them yourself.
I think the point is not your application team asking why trigger EVERY is included in the product, but you asking them why they need to use it? What is it about their requirements that precludes FIRST or other trigger types?
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| sidharth_bora |
| Posted: Wed Aug 22, 2007 2:04 am Post subject: |
|
|
Voyager
Joined: 24 Nov 2005
Posts: 87
|
Thanks Vitor for your input. I agree with all the GM's and all in this thread.
But iam in need of resolution to this problem, as the application code was well done before i joined the org,i cant directly askt them to change the code now ,as its in PROD, of course for the new design, i will certainly highlight the points suggested by you all.
For now, please help me with tuning considerations or any other resolution to resolve this issue.
regds
Sid |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Wed Aug 22, 2007 2:07 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
As an aside: we only use trigger every on the mainframe and then the application is CICS resource throttled (max concurrent instances).
Also remember that each trigger every processing program needs to be written as if it were use with trigger first.
Enjoy 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Aug 22, 2007 2:18 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| fjb_saper wrote: |
Also remember that each trigger every processing program needs to be written as if it were use with trigger first.
|
Which I suspect is the point in the original post & why messages are getting stuck. Because this application team are using trigger EVERY they've written the code to read a single message on the flawed assumption each message will trigger a successful transaction.
For the record, I've only ever used trigger EVERY in the same way - on mainframe, resource throttled through CICS and under protest!
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Wed Aug 22, 2007 9:51 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
The original programmmers made an incorrect assumption: That every MQ message on the queue will always always generate a trigger message. Because of this incorrect assumption, they coded the program wrong. It doesn't reads until the queue is empty, it reads only one message and ends. This opens up the possability of orphaned messages on the trigger queue.
It doesn't mean it will happen every day, every week or even every year. But it will eventually happen as you've discovered. So the fact that the other programs are working fine doesn't prove anything. I haven't won Powerball yet but that doesn't mean I won't win tonight, right? 
Change Trigger type to first. And set trigger interval to a reasonable value (search here for details). This will put a band aid over the program not reading until the q is empty. It may sometimes cause excessive triggering, but that's the apps fault for not clearing the queue when its started.
The app should also be changed to read until the queue is empty. Why? Because its one of the "rules" for MQ programming. Triggered apps read until 2033.
There are your arguements for telling them to fix it.
While I agree that Every should be very rarely used, I can surely come up with a reason why. Lets say an app takes 1 minute to process a message and the reply needs to come back in 2 minutes. Lets say you sometimes get 10 or so messages a minute. Obviously you need some parallel processing and Trigger Every will help. (I assume you can't have more servers and you can't speed up the 1 minute processing time) Because multiple instances will run concurrently when multiple messages arrive. But those apps each have to read until the queue is empty.
Now Trigger On Group, that's something I think IBM should implement (only trigger when the entire group is there).
Moving this to the MQ General Support Forum. Its got nothing to do with WMB.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| George Carey |
| Posted: Thu Aug 23, 2007 7:54 am Post subject: Peter's response on Triggering |
|
|
Knight
Joined: 29 Jan 2007
Posts: 500
Location: DC
|
Somewhat off the cuff bumped into this post but thought it worth commenting on the final response by PeterPotkay.
Excellent example, lucid and clearly stated! Other responders should try to emulate his style, instead on a too frequently seen smarmy, glibness.
Notice, there are no more additions since Peter's, for a good reason!
Cheers
_________________
"Truth is ... grasping the virtually unconditioned",
Bernard F. Lonergan S.J.
(from book titled "Insight" subtitled "A Study of Human Understanding") |
|
| Back to top |
|
|
|
|
