| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
| Triggering – First & Every |
View previous topic :: View next topic |
| Author |
Message
|
| ata_nitjsr |
 Posted: Fri Oct 17, 2008 4:07 am Post subject: Triggering – First & Every |
 |
|
Acolyte
Joined: 08 Apr 2007
Posts: 56
|
I have a management problem
I have to change the triggering type from “First ” to “Every”.
Would there will be any performance issue? |
|
| Back to top |
|
 |
| PeterPotkay |
| Posted: Fri Oct 17, 2008 4:08 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
Most likely things will take a turn for the worse.
Why are you doing this? You have to have very specific reasons to make the decision to use Every over First.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Fri Oct 17, 2008 6:32 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
| Quote: |
| Would there will be any performance issue? |
This one of those 'Yes, no, and it depends.' questions.
EVERY means that (potentially) an instance of the triggered application will be launched for every message that arrives. If lots of messages arrive, lots of consuming applications will be launched. So, it depends.
If your server has lots of horsepower, enough to handle lots of consuming applications, then likely, No.
If your server has limited horsepower, then probably, Yes.
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Fri Oct 17, 2008 6:40 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
Yes, you will see a performance issue.
More CPU will be consumed. More memory will be consumed. These will be measurable, and you can report on them.
Will that "issue" be an "impact", that has negative consequences and requires management or monitor?
That's what depends.
If you have 10Gb of ram in the machine, and your app normally uses 40k of RAM, then running two copies to use 80K is not an issue - unless that's the last 40k that was free. |
|
| Back to top |
|
|
| kevinf2349 |
| Posted: Fri Oct 17, 2008 7:10 am Post subject: Re: Triggering – First & Every |
|
|
Grand Master
Joined: 28 Feb 2003
Posts: 1311
Location: USA
|
| ata_nitjsr wrote: |
I have a management problem
I have to change the triggering type from “First ” to “Every”.
|
What management problem? Do you mean a problem with managing the application or a problem with your managers sticking their noses into things and failing to understand the implications of their 'wisdom'? |
|
| Back to top |
|
|
| ata_nitjsr |
| Posted: Mon Oct 20, 2008 1:39 am Post subject: |
|
|
Acolyte
Joined: 08 Apr 2007
Posts: 56
|
|
| Back to top |
|
|
| sebastia |
| Posted: Mon Oct 20, 2008 2:02 am Post subject: |
|
|
Grand Master
Joined: 07 Oct 2004
Posts: 1003
|
mr Bruce : can you explain your phrase a bit more ?
You say "EVERY means that (potentially) an instance of the triggered application will be launched for every message that arrives"
What is wrong with it ?
If I define a transmit queue to work "TRIGTYPE(EVERY)"
and I use "initq(SYSTEM.CHANNEL.INITQ)"
do you mean "runmqchi" will be launched ...
... for every message that arrives ?
BUT THAT IS EXACTLY WHAT WE WANT, don't we ? |
|
| Back to top |
|
|
| David.Partridge |
| Posted: Mon Oct 20, 2008 2:24 am Post subject: |
|
|
Master
Joined: 28 Jun 2001
Posts: 249
|
No absolutely not what you want. When you set up a trigger on a transmission queue, you set up TRIGTYPE(FIRST), so that the first message on the queue will drive the channel initiator to start the channel. The channel will then start and will process not just this message, but any subsequent messages that land on the TQ. If no messages land on the TQ after the DISCINT time, then the channel will go inactive.
Next time another message lands on the TQ, the whole process starts again.
_________________
Cheers,
David C. Partridge |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Mon Oct 20, 2008 6:13 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
There are two types of trigger monitors supplied with WMQ, namely: runmqtrm - used to start applications when a message arrives in a triggered application queue; and runmqchi - the channel initiator - used to start a channel when a message arrives in a transmission queue.
| Quote: |
You say "EVERY means that (potentially) an instance of the triggered application will be launched for every message that arrives"
What is wrong with it ? |
My response was about the runmqtrm trigger monitor; not the channel initiator.
Your choice of NONE, FIRST, EVERY and DEPTH, is about starting your consuming application program.
By was of disclaimer: If your service-level agreement demands concurrent executions of the consuming application to service multiple application messages, AND your server platform has lots of horsepower, then triggering the consuming application on EVERY message arrival launch multiple instances of the consuming application. There is nothing wrong with this approach - it works.
Runmqtrm source is supplied. You can tinker and tune it to launch whatever and how many consuming applications you want.
Scenario: 1. requesting application MQPUTs a message arrives in the application queue; and 2. the consuming application MQGETs the request message and does the back-end database update; and 3. MQPUTs the reply message to the reply-to-queue; and 4. the requesting application MQGETs the reply message; and 5. communicates this to the end-user.
With trigger type FIRST (only one instane of the consuming application): IF your SLA for all this, processes 1. through 5., is not to exceed two seconds, AND it takes one second to complete; then the first message and the second message will both be in service-level. The third and subsequent will NOT. Simple math: each message takes one second, three messages = 3 seconds.
With trigger type EVERY (disclaimers: no message affinity, sufficient horsepower, consuming application does a MQGET with WAIT, and ...), each message arrival would (potentially) launch another instance of the consuming application. I say potentially, because the first instance would likely have completed the processing of the first message in time to consume the third message or fourth message. It's a more complicated statistical math model; but should be somewhat intiutive.
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Mon Oct 20, 2008 6:19 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
| Quote: |
I define a transmit queue to work "TRIGTYPE(EVERY)" ...
BUT THAT IS EXACTLY WHAT WE WANT, don't we ? |
Regarding triggering an xmit queue:
David.Partridge's response is correct. A single sending MCA (what gets launched when you issue a START CHANNEL command or runmqchi starts the channel.
What is it that you want? Multiple MCAs getting messages from a single xmit queue?
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| sebastia |
| Posted: Mon Oct 20, 2008 6:27 am Post subject: |
|
|
Grand Master
Joined: 07 Oct 2004
Posts: 1003
|
mr Bruce - I have understood your idea, I think.
Application replica is launched EVERY time.
Now, let me re-write my question :
What happens if I select EVERY for RUNMQCHI ?
================================
For EVERY message placed in the Transmit Queue,
the program RUNMQCHI starts,
and tests if channel is running.
If it is running, nothing to do.
If it is not running, start the channel.
Looks nice to me !
Yes, if a "bunch" of messages are placed in the TxQ,
the test is done few extra times ....
mr David - in your reasoning, I dont understand the meaning
of the word "FIRST" - you say
"Next time another message lands on the TQ ..."
How can you tell it is the FIRST message ?
For me, FIRST only happens ONCE in a lifetime.
For you, it looks you have again a FIRST message .... after a while
Guess EVERY means
"if the previous processing has not ended,
start another copy of the program ...
Otherwise do as if it were FIRST" ...
while FIRST means - do not start a second copy of the processing program |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Mon Oct 20, 2008 6:51 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
Once started, channels remain in RUNning state until the disconnect interval (or the channel fails). This is different than user-focused applications.
The trigger data field on the xmit queue is used to identify to the channel initiator application (runmqchi) the name of the channel to start. So, a single instance of the runmqchi is sufficient to start a channel on the arrival of the FIRST message, and to keep channels running.
From the manuals: FIRST means that queue depth goes from 0 to 1; so it is not a once-in-a-lifetime event. Why? The MCA will get messages from the xmit queue, and the depth will go to zero again. Next message will be viewed by the channel initiator as FIRST when depth once again goes form 0 to 1.
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Mon Oct 20, 2008 7:08 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
Whether you use Every or First or Depth, make sure your triggered program is written to read until the q is empty. DO NOT have it only read one message and end. If you use Trigger Every and only code to read one and done, sooner or later you will end up with a rolling backlog of messages on the queue and wonder why MQ triggering is "broken". There have been a few detailed posts here why this can happen.
And all triggered programs should be written to deal gracefully with finding an empty queue on their first MQGET.
As you are finding out, triggering is not quite as simple as it appears at first glance. Read the triggering chapter in the MQ Info Center in the App Programming Guide. Then read it 3 more times. Searching this website for posts related to Trigger Interval and also Trigger Every will save you lots of trouble in the future.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Mon Oct 20, 2008 7:23 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
| Quote: |
| DO NOT have it only read one message and end. |
PeterPotkay is pointing out that it takes a huge amount of effort (cpu cycles, i/o) to instantiate an application - perhaps more than the consuming application will use to process the message.
You don't want to cause this for each message that arrives. Applications should be coded to MQGET with WAIT, and repeat this sequence to allow for messages to arrive without re-instantiating the consuming application. It takes far less effort to get/wait.
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Mon Oct 20, 2008 7:29 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| bruce2359 wrote: |
| Quote: |
| DO NOT have it only read one message and end. |
PeterPotkay is pointing out that it takes a huge amount of effort (cpu cycles, i/o) to instantiate an application - perhaps more than the consuming application will use to process the message.
|
I don't disagree with that, but what I was really pointing out was that if you use Every, and code for one and done, you WILL end up sooner or later with a rolling back log of messages on the queue. The next message hits, you get ONE trigger message even though you may have 50 messages backed up, the triggered app get message # 1, while messages #2 thru #51 sit, and the cycle continues. MQ Triggering is not broken in this case, the program's design is.
Trigger Every does not mean Trigger for each and every and any message that might be there.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
|
|
|
  |
Goto page 1, 2 Next |
Page 1 of 2 |
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
|
|
