| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
| Triggering – First & Every |
« View previous topic :: View next topic » |
| Author |
Message
|
| sebastia |
 Posted: Mon Oct 20, 2008 7:33 am Post subject: |
 |
|
Grand Master
Joined: 07 Oct 2004
Posts: 1003
|
no, I dont want multiple MCA
I am saying the runmqchi will receive a trigger message
on every data message put into the transmit queue
so, it will receive lots of them
but will start the channel only once - when it finds it stopped.
Peter - I am not talking about triggering own applications.
My applications loop until queue empty,
and mr Bruce ... we do NOT WAIT in the GET method,
because we are in a triggered environment,
as far as I understand it. |
|
| Back to top |
|
 |
| sebastia |
| Posted: Mon Oct 20, 2008 7:43 am Post subject: |
|
|
Grand Master
Joined: 07 Oct 2004
Posts: 1003
|
Peter - I agree with you 99%+ of the time, but today ...
From MQSC command ref :
TRIGTYPE
Whether and under what conditions a trigger message is written to the initiation queue (named by the INITQ parameter).
EVERY
Every time a message arrives on the queue
with priority equal to or greater than that
specified by the TRIGMPRI parameter of the queue.
Anyway, I think I understand what you are trying to say :
there are situations you will have
less trigger messages than data messages.
I have read few other posts about it ...
And I think I can handle that.
So, conclusion is
(a) use "FIRST" in TRIGTYPE
(b) loop on MQ_Get() until empty queue, gmo.waitInterval = 0 ;
am I right ? |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Mon Oct 20, 2008 7:47 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7723
|
What don't you agree with? 
| Quote: |
So, conclusion is
(a) use "FIRST" in TRIGTYPE
(b) loop on MQ_Get() until empty queue, gmo.waitInterval = 0 ;
am I right ? |
Use trigger first in most cases, use Depth or Every where needed, which 99.9% of the time is not needed.
Read until 2033, yes, and best practice for triggered app is to wait for a little bit for any more messages, to avoid a fluttering trigger scenario. If you expect to get messages once an hour, and ONLY once an hour, you are right, why wait. But if you cannot guarantee 100% the arrival rate of new messages, then you should wait a bit to make sure no more messages arrive.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Mon Oct 20, 2008 9:04 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9482
Location: US: west coast, almost. Otherwise, enroute.
|
| Quote: |
| ...we do NOT WAIT in the GET method, because we are in a triggered environment, as far as I understand it. |
Posts here have pointed out that if your applicaiton does an MQGET, processes the message, then ends the application; the next message will require another instance of the consuming application be created. This is costly in both resourcs and TIME.
Applications should be coded with MQGET with wait (5 seconds, 30 seconds, 1 minute). Waitinterval 0 indicates no wait.
If a message already exists in the queue, there is no wait - the application instantaneously gets the message. If a message arrives withing the wait period, the wait terminates and the application gets the message.
If no message arrives on the queue, the wait ends, the app gets a 2033 (no message available), the program does another get/wait; then repeats appropriate number of times (10, 100, 1000) to ensure that another message arrving does not needlessly require a new instance of the application to be launched.
_________________
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 10:14 am Post subject: |
|
|
Grand Master
Joined: 07 Oct 2004
Posts: 1003
|
Peter - I started in a "disagree" mode, and ended in "you are right" mode !
()
Anyway, "wait a bit" is a size I do no understand ...
Whatever size your bit is, the message can come one thousandth (1/1000)
of a second later, making the trigger mechanism work again.
Yes, it's called Murphy's law.
So, after first 2033, no more waits.
... fluttering .. interesting word ....
Bruce : if we go trigger mode, we do trigger.
If we loop in GMO_WAIT mode, it is polling,
and Best Practices say "go trigger mode, no polling" ...
We are talking about the MQGET() after 2033.
If a msg is in the que, I agree there is no delay.
But why shall I wait 5 seconds, if MQ will wake up my code
when the message arrives ?
(and that will be 5 seconds plus 1/1000 of a second after 2033, of course)
Thanks for sharing your opinions ! |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Mon Oct 20, 2008 10:37 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7723
|
| sebastia wrote: |
Anyway, "wait a bit" is a size I do no understand ...
Whatever size your bit is, the message can come one thousandth (1/1000)
of a second later, making the trigger mechanism work again.
Yes, it's called Murphy's law.
So, after first 2033, no more waits.
|
Absolutley, and this is where it's important that the MQ Admin setting up the system understands the MQ traffic patterns related to this app.
x = the amount of time that you don't want to retrigger more often than. Lets say that's 30 seconds. Your environment dictates this. Maybe you don't want your app connecting to the QM, opening queues, loading variables, connecting to DBs, etc more often than every 30 seconds, or 30 minutes.
Set your wait interval to x milliseconds.
y = the average length of time in between new messages.
If y is longer than x, you will retrigger when you need to, otherwise your app is dormant. If y is less than x, than your app fires up once, probably the first time in the morning, will probably stay running all day long, saving all those CPU intensive activities that happen at app start up and shutdown, and then at the end of the business day nicely end for the night, but will be ready for the next message next morning, or for that late message in the middle of the night.
You will never eliminate a message arriving 1/1000th of a second after your Get with wait ends. But if you nail down x and y this will be a rare occurance with no consequences.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| kevinf2349 |
| Posted: Mon Oct 20, 2008 10:47 am Post subject: |
|
|
Grand Master
Joined: 28 Feb 2003
Posts: 1311
Location: USA
|
| sebastia wrote: |
and Best Practices say "go trigger mode, no polling" ...
|
By polling they (who ever 'they' are) mean that the program sits around all day just "popping" a 2033 and then going back to wait.
There are many styles for applications and the choice of design is really a business decision. The decision isn't an 'across the board' system wide decision...it is an application busniess choice.
The important part of it all is to fully understand triggering and it's various types. Each have their own little quirks and 'issues to be dealt with'. It is important to understand these when you design the application.
As a general rule I always use FIRST unless I have a really good business case to not do so.
I always use FIRST for channel triggering. (Although EVERY can bail you out from a backlog on the transmission queue) and I always code a disconnect interval...why? Well this has been discussed at length in these forums.
The bottomline is there is no one 'right' answer....just lots of wrong or undesirable ones....but you need to fully understand the way that tirggering works because it could (and I would say should) effect how the application flow is coded.
Just my 2 cents |
|
| Back to top |
|
|
| sebastia |
| Posted: Mon Oct 20, 2008 10:53 am Post subject: |
|
|
Grand Master
Joined: 07 Oct 2004
Posts: 1003
|
Peter - I have to confess I just used googleMaps to locate "Hartford CT",
a place where you can ask for
"average length of time in between new message"
and get an answer.
By the way, I went to New Hampshire few years ago,
contact admin was the town. I did enjoy the place, of course.
And the shuttle from Boston to NY.
Let me tell you how my country goes :
Last week I went to install MQ on a new customer,
with only 1 Application
(having 30 or more of them does complicate the figures, doesn't it ?)
and I asked for average message size,
and the number of messages per day,
to calculate the MQ log size ...
They are still laughing.
I talked to the hw people, they had enough disk,
so I got 20 GB for the log.
Cheers. Seb. |
|
| Back to top |
|
|
| sebastia |
| Posted: Mon Oct 20, 2008 11:00 am Post subject: |
|
|
Grand Master
Joined: 07 Oct 2004
Posts: 1003
|
Kevin - that kind of discussion is what I am looking for in this forum.
I can agree or not, you can use this method or the other,
but sharing the experiences is the main point.
Let me say I always use DISCINT=0 .... ()
unless TCPIP is noisy and fills AMQERR01.LOG with errors ...
I have to agree - I used trigger on every just to make sure
I shall miss less data messages that with FIRST choice.
Now, I shall use it quite less for runmqchi ...
and shall (try to) code better applications ...
By the way, I know there is a way to know there is your code
already running in the machine,
so I can limit the number of my code "replicas" ...
Maybe I will NEVER understand triggering completely
(just dont have enough time ...) |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Mon Oct 20, 2008 11:16 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9482
Location: US: west coast, almost. Otherwise, enroute.
|
| Quote: |
| Maybe I will NEVER understand triggering completely (just dont have enough time ...) |
As you have discovered, triggering is not a subject existing in a vacuum. Neither is the MQGET call. Neither is channel operation.
Your responsibility is to understand how all the parts fit and behave if you are to achieve the service-levels that your organization has established.
_________________
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 11:34 am Post subject: |
|
|
Grand Master
Joined: 07 Oct 2004
Posts: 1003
|
I was a milimeter to agree, but just can't.
mr Bruce ... you sound very responsible of your job.
But there is something more important that your job.
And it is your life.
And let me tell you a secret I have learned
( I suspect I am quite older than you ... () )
Happiness is ... to know nothing is too important.
I am very good with triggering and MQ, you can trust me,
but better with red wines.
Cheers. Seb. |
|
| Back to top |
|
|
|
|
|
|
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
|
|
|
|
