| Author |
Message
|
| Priya |
 Posted: Mon Mar 25, 2002 4:22 am Post subject: |
 |
|
Apprentice
Joined: 20 Mar 2002
Posts: 26
|
There is a program X, which retrieves the message from the queue and call some function, processes the message and put the reply back to another queue. Which is a good design, (i) Queue Manager triggers the program X every time message arrives on the queue – so multiple instance of the program will be running if the queue receives more messages (ii) the Program X will be running all the time waiting for the message in the queue. Once it gets the message, process it and put the message back to another queue and retrieve the next message…
Please help me out...
Thanks
Priya
|
|
| Back to top |
|
 |
| mathiss |
| Posted: Mon Mar 25, 2002 5:27 am Post subject: |
|
|
Novice
Joined: 21 Jan 2002
Posts: 12
Location: Harrisburg, PA
|
The best way to decide would be to look at your capacity and usage. A third approach could be a program to start when the first message hits the queue and continue to process until there are no more messages. All of these are functional ideas but you do need to look at the usage of this program and see which idea is best for your application and platform.
Sue |
|
| Back to top |
|
|
| Priya |
| Posted: Mon Mar 25, 2002 6:31 am Post subject: |
|
|
Apprentice
Joined: 20 Mar 2002
Posts: 26
|
Suppose I trigger the application when first message arrives, It works in such a way that when the number of message on the queue goes from 0 to 1 it treats that message is a first message and trigger the application.
(i) When the application retrieves the first message it becomes 0 when second message arrives then it triggers the next instance of the application as no of message goes form 0 to 1. Am I right?
(ii) Also for some system problem the application may not able to start or run. In that case we have to set the triggering Interval. If we set this as small number then it will be same as EVERY. How to set that interval and avoid the problem?
Thanks
Subha
|
|
| Back to top |
|
|
| zpat |
| Posted: Mon Mar 25, 2002 6:49 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5849
Location: UK
|
People get hung up on triggering. It has no great advantage and often produces a worse design.
A long running program waiting for arriving messages performs only a single MQGET per message. A triggered program results in an extra MQPUT and MQGET of the trigger message as well as the MQGET of the data message.
The main reason to use triggering is to avoid running a program that is only need very occasionally. In a real-time medium to high volume system it is inefficient to use triggering and unnecessary.
You can always run several long-running programs against the same queue to provide enough capacity and load-balancing. In fact you really don't want too many programs starting - if a large number of messages arrived you would break the system.
Think of triggering for occasional message arrival (eg once per hour or day) if you are looking at several per minute or second - don't use it. |
|
| Back to top |
|
|
| Priya |
| Posted: Mon Mar 25, 2002 7:49 am Post subject: |
|
|
Apprentice
Joined: 20 Mar 2002
Posts: 26
|
The long running program gets the message from the queue on FIFO basis, process it and put the reply back in to another queue. Once this is done the loop has to be there to wait for another message indefinitely (unlimited wait) to get another message and do the same.
In this case if large number of message arrives then processing will not be fast enough if one instance of the application is running.
How to handle this?
If I am wrong please advise me
Thanks
|
|
| Back to top |
|
|
| zpat |
| Posted: Tue Mar 26, 2002 12:50 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5849
Location: UK
|
Like I said, start more than one long-running program against the same queue, waiting for messages is perfectly OK.
You could perhaps trigger extra copies of the program using a trigger on queue depth so that if the queue fills up, it starts more receiver tasks.
Like I said, if you trigger one program per message, you will swamp your server if a large number of messages arrive at once (as well as doing extra MQGET and MQPUTs for no good reason).
You need to give us more to go on - how many messages per second might arrive, how long does it take to process each message, how many receiver tasks would be able to run concurrently on your platform etc etc?
If the processing is CPU intensive, there is not much point in starting more programs concurrently than the number of CPUs.
[ This Message was edited by: zpat on 2002-03-26 00:51 ] |
|
| Back to top |
|
|
|
|
