| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| To Trigger or NOT To Trigger ? |
« View previous topic :: View next topic » |
| Author |
Message
|
| vikram |
 Posted: Mon Jun 03, 2002 5:45 am Post subject: To Trigger or NOT To Trigger ? |
 |
|
Newbie
Joined: 03 Jun 2002
Posts: 4
|
Greetings !
We are working on the design for an application with the foll. scenario.
- About 1500 messages a day (across 8 hrs) .
- Process each message and send a message back to the requester.
- Each message will take about 2-3 secs processing time and we need to
ensure parallel processing, i.e if 10 messages are on queue then all 10
must be taken up for processing.
-- deployment is on SOLARIS and application logic in JAVA.
Questions :
1. Is triggering a correct approach ?
2. Will MQ trigger another process if the first one is already running
(Parallel processing).
3. How to handle situations when MQ goes down and there are still some
messages on the Queue (with Triggering "EVERY" enabled)
- All suggesions are welcome.
Many Thanks
Vikram. |
|
| Back to top |
|
 |
| bduncan |
| Posted: Mon Jun 03, 2002 8:34 am Post subject: |
|
|
Padawan
Joined: 11 Apr 2001
Posts: 1554
Location: Silicon Valley
|
Vikram,
From my initial impressions, here's some quick answers. We could probably refine these answers based on more information about your particular setup (message affinity, syncpoint requirements, etc.)
| Quote: |
| 1. Is triggering a correct approach ? |
Perhaps - the answer will depend on how you code the application to be triggered, and your business requirements. If you write the application such that it processes a single message, and then exits, you can use trigger type EVERY. However, this potentially creates a huge overhead. You said it takes 2-3 seconds to process a message. Imagine that the messages are coming in at a rate of 1 every 4 seconds. Your application will be triggered, process a message in 3 seconds, exit, and then be triggered again 1 second later when the next message comes in. This is very inefficient. However, if you have the same scenario but the messages are arriving 1 every .5 second, then it becomes more efficient. Your queue manager could trigger multiple copies of the application (since we are using trigger type EVERY) and although each copy would still only process a single message, you would have several of them running at once. From the scenario you described (1500 in an 8 hour period) that comes out to about 1 message every 20 seconds. Because the messages are spaced so far apart, the startup-shutdown overhead incurred each time your application is triggered will be insignificant (especially since you'll only be processing for 3 seconds, and then idle waiting for potentially 17 seconds). Since the frequency of messages seems pretty low (correct me if your setup is such that there are spikes of activity followed by relative inactivity, in which case my answer will be different) I would recommend triggering on type FIRST, and instead of processing a single message, process all messages on the queue. Once you get a 2033, then you can exit. This approach doesn't necessarily mean no-parallel processing. Although MQSeries won't trigger multiple instances of the process, you can use threading within the process itself.
| Quote: |
| 2. Will MQ trigger another process if the first one is already running (Parallel processing). |
Yes - assuming the trigger condition is met - again. In other words, MQ won't trigger another process simply because one is already running. As always, MQ only triggers an application if the trigger condition is met. It doesn't care if there are 0,1, or n processes running which have previously been triggered.
| Quote: |
3. How to handle situations when MQ goes down and there are still some messages on the Queue (with Triggering "EVERY" enabled)
|
Not much - aside from getting MQ back up. If MQ is down, obviously your application won't get triggered. If it was already triggered, and MQ goes down while it is running, your application won't be able to PUT, GET, or anything else with respect to the queue manager.
_________________
Brandon Duncan
IBM Certified MQSeries Specialist
MQSeries.net forum moderator |
|
| Back to top |
|
|
| vikram |
| Posted: Tue Jun 04, 2002 4:57 am Post subject: |
|
|
Newbie
Joined: 03 Jun 2002
Posts: 4
|
Brandon,
Thanks a lot, Your response was quite useful.
We are exploring the option of developing a JAVA application which will be triggered on arrival of FIRST message. This application will GET messages from the local queue and spawn a new thread for each message received. This thread will process the message, format the response and PUT a message back into the remote Queue.
Are there any known issues with using multi-threaded application with mq ?
Are any sample multi-threaded java programs with mqseries available on the net ??
Thanks again
Vikram. |
|
| 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
|
|
|
|
