| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| Triggering versus infinite loop |
« View previous topic :: View next topic » |
| Author |
Message
|
| sebastia |
 Posted: Sat Jun 29, 2013 12:12 pm Post subject: Triggering versus infinite loop |
 |
|
Grand Master
Joined: 07 Oct 2004
Posts: 1003
|
I have always tried to make my answering applications run in triggering mode, as no resources are waisted while there is no traffic.
But a triggered MQ program has to do always the complete sequence ...
1) mq_connect()
2) mq_open()
3) mq_get()
4) mq_close()
5) mq_disconnect()
A "infinite loop" mq program consumes system resources, but stays only on the (3) get operation forever ...
Is there any way to keep the "connect" and "open" handles alive so I can configure a "triggered" mq program, without the need on using mq_connect() every time ?
Sebastian.
PD.- guess the pseudo-code would be :
| Code: |
forever_loop:
mq_read() ;
if ( rc = not connected ) then mq_connect() ;
if ( rc = not open ) then mq_open() ;
if ( rc = OK ) then ...
goto forever_loop ;
|
|
|
| Back to top |
|
 |
| bruce2359 |
| Posted: Sat Jun 29, 2013 2:52 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
The most straight-forward method is to modify the triggered app from mqget to qget to mqget with wait/waitinterval.
If a message is in the queue the program will consume it immediate,y. If no message is available, the mqget call will wait waitinterval. When a message arrives the wait will end, and the program will consume the message. If the waitinterval expires, the app will get a ReasonCode 2033. This is where your loop belongs.
For example, you might set waitinterval to 1 minute. After 10 loops (10 minutes) with no messages available, you could end the program, and wait for it to be re-triggered.
_________________
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 |
|
|
| zpat |
| Posted: Sat Jun 29, 2013 10:24 pm Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
A hybrid as above is a good idea. But a MQGET WAIT is not a waste of system resources. It will only consume a small amount of memory.
There is the call back option as well in MQ v7.
It really depends how often it would be triggered. If it's less than once per hour then triggering seems fine. If it's more than one per minute then MQGET WAIT is better. In between - take your pick or use the hybrid.
It is though vital to set the wait interval on the MQGET MQGMO_WAIT and not allow it to loop around in a CPU loop. Also don't sleep in your own code because then you get latency. Letting the QM wait for you means no latency when a message does arrive.
In both cases the triggered program should consume all the messages in the queue before terminating. Trigger (first) should be used. |
|
| Back to top |
|
|
| sebastia |
| Posted: Sun Jun 30, 2013 1:28 am Post subject: |
|
|
Grand Master
Joined: 07 Oct 2004
Posts: 1003
|
Bruce : interesting idea to use MQGET() sometimes with "wait interval" and sometimes without ...
ZPAT : you have touched an item I am VERY INTERESTED IN : callback
Can you provide me some pointer / url about this function ?
Is it new starting v7 ?
What is its complete "name" so i can search publib ?
Thanks ! Sebastian. |
|
| Back to top |
|
|
| sebastia |
| Posted: Sun Jun 30, 2013 1:36 am Post subject: |
|
|
Grand Master
Joined: 07 Oct 2004
Posts: 1003
|
|
| Back to top |
|
|
| zpat |
| Posted: Sun Jun 30, 2013 1:53 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
| sebastia wrote: |
Bruce : interesting idea to use MQGET() sometimes with "wait interval" and sometimes without ...
|
You can always code MQGMO_WAIT, as this only causes an actual wait if the queue is empty otherwise it returns the message immediately.
When waiting it will return the next message immediately it arrives. If however the wait interval expires without any message arriving then you get the 2033 returned.
So you could set wait interval to one minute on all the MQGET calls and terminate when 2033 is returned.
This is what I meant by a hybrid design - triggered but then it lingers a bit to avoid being triggered again within that wait interval period.
Last edited by zpat on Sun Jun 30, 2013 1:55 am; edited 1 time in total |
|
| Back to top |
|
|
| sebastia |
| Posted: Sun Jun 30, 2013 1:55 am Post subject: |
|
|
Grand Master
Joined: 07 Oct 2004
Posts: 1003
|
mr ZPAT : thsnka for the 2033 stuff ... but ...
the callback function opens the door to use MQ from JAVASCRIPT, and this looks very interesting to me ! |
|
| Back to top |
|
|
| sebastia |
| Posted: Sun Jun 30, 2013 2:32 am Post subject: |
|
|
Grand Master
Joined: 07 Oct 2004
Posts: 1003
|
I am having a look at c:\mq\tools\c\samples\amqscbf0.c
Looks interesting ... |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Sun Jun 30, 2013 4:45 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
| sebastia wrote: |
| Bruce : interesting idea to use MQGET() sometimes with "wait interval" and sometimes without ... |
I was not suggesting 'sometimes without.' Read carefully zpat's replies.
Conserving (vs. wasting) resources is generally a good idea.
Which resources are you trying to conserve? Physical resources, like disk space, cpu, RAM? Or the other kind, like the human developer time, problem-determination time? Conservation should be one design consideration, but not the primary consideration. Just like in the real world, conservation of one resource impacts (wastes) another. A few broad examples:
You mentioned using Java. Java is a memory and cpu hog. Java requires a JVM. If you want to conserve cpu and memory, don't code Java; rather, code in an assembly language. Of course, Java is often quick to code, saving developer time.
If you want to conserve cpu and disk space, don't use relational databases, as they squander both. Of course, relational databases allow app run-time flexibility.
Instantiating an application (acquiring virtual- and real-storage, finding the app in some library, having the o/s load the app from disk, schedule it to execute, ...) all of this takes substantial o/s resources. Generally, it is better to instantiate once, and let the app consume many messages. Waiting for another message to arrive takes far, far fewer resources.
A badly designed mq app would come to life, consume one message, then immediately end itself - without checking (get/wait) to see if other messages are available to be consumed. In this badly-designed app, if more messages remain in the queue, the app would need to be instantiated for each message - a waste of resources.
Specifically, which resource(s) are you trying to conserve?
_________________
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: Sun Jun 30, 2013 9:58 am Post subject: |
|
|
Grand Master
Joined: 07 Oct 2004
Posts: 1003
|
Hi, Bruce - definitelly, physical ones, this is RAM and CPU.
No Java involved, no DB2.
What I wanted to do is not to call MQ_Connect() everytime triggering wakes my code up.
Now I see that if we have lots of messages, the wait+interval solution is better.
Thanks. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Sun Jun 30, 2013 12:10 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
| sebastia wrote: |
What I wanted to do is not to call MQ_Connect() every time triggering wakes my code up. |
Triggering does not wake your code up. Rather, it tells the o/s to load your program, and to pass control to it. All this is very labor-intensive.
| sebastia wrote: |
Now I see that if we have lots of messages, the wait+interval solution is better.
Thanks. |
MQGET with wait+waitinterval presumes that your program is already instantiated, is MQCONNected, has MQOPENed the queue, and merely waiting for a message to arrive in the queue. Waiting for a message to arrive in the queue takes very few resources.
_________________
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 |
|
|
| Andyh |
| Posted: Mon Jul 01, 2013 12:41 am Post subject: Callback performance |
|
|
Master
Joined: 29 Jul 2010
Posts: 239
|
| Using the MQ V7 callback mechanism provides some interesting extensions, for example the ability to wait upon multiple queues concurrently, however for an application simply consuming messages from a single queue, on the distributed platforms, a simple MQGET is typically more efficient, both in terms of CPU and memory consumption. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Mon Jul 01, 2013 4:03 am Post subject: Re: Callback performance |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
| Andyh wrote: |
| Using the MQ V7 callback mechanism provides some interesting extensions, for example the ability to wait upon multiple queues concurrently, however for an application simply consuming messages from a single queue, on the distributed platforms, a simple MQGET is typically more efficient, both in terms of CPU and memory consumption. |
I'm guessing that you meant that a simple MQGET with wait/waitinterval is typically more efficient...
_________________
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 |
|
|
| Andyh |
| Posted: Mon Jul 01, 2013 4:16 am Post subject: Triggering vs MQGET + MQGMO_WAIT |
|
|
Master
Joined: 29 Jul 2010
Posts: 239
|
Sorry, I took it for granted that MQGET with wait would be used in a performance sensitive environment.
MQCONN, MQDISC, MQOPEN and MQCLOSE are generally CPU and lock bound. MQGET and MQPUT are typically I/O bound (on the recovery log) for persistent messages, and CPU or lock bound for non-persistent messages.
Even in the case where the MQCONN and MQOPEN are cached, there are significant potential advantages from having at least one outstanding MQGET with MQGMO_WAIT as this can allow the message to be passed from an MQPUT to an appropriate MQGET without actually ever being placed on the queue. This has significant advantages from both a locking and a CPU utilization perspective. |
|
| Back to top |
|
|
|
|
|
| |
|
Page 1 of 1 |
|
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
|
|
|
|
