| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| Prioritising RealTime msgs over Batch |
« View previous topic :: View next topic » |
| Author |
Message
|
| Dhiren |
 Posted: Wed Aug 04, 2010 10:27 pm Post subject: Prioritising RealTime msgs over Batch |
 |
|
Novice
Joined: 27 Jan 2005
Posts: 17
|
We are currently processing Batch and RealTime transactions using Message Broker flows. Both transactions are functionally similar and should be processed similarly.
Batch and Online arrive on separate queues and have to be processed in the logical order they arrive (ordering not required across Batch and RealTime).
Batch is not scheduled and can occur anytime during the day and can even coincide with RealTime transactions. Both transactions are 24/7.
There is no affinity b/w Batch and Real-time messages, they can be processed individually (but within their groups they are have to be processed serially).
We now have a new (QoS) requirement to process RealTime transactions on a priority over Batch Transactions.
We have brainstormed a few early ideas such as :
- Deploying Batch and Realtime message flows on separate Execution Groups with different capacity and therefore processing them at different rates,
- Scheduling Batch transaction by using TimerControl / TimerNotification nodes,
- MQ level message Prioritisation on RealTime messages..
Any ideas/ suggestions / past experience will be appreciated
(MB/MQ - v6.0) |
|
| Back to top |
|
 |
| zpat |
| Posted: Wed Aug 04, 2010 11:28 pm Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
Using MQ message priority is easy and can even be achieved with no programming changes, simply by using queue aliases with different default priority values.
Execution groups cannot easily be given different processing capacities (although it could be done using WLM on AIX or z/OS).
To achieve higher throughput you could at parallelising the messages, for example if the sequence requirement is really per customer, simply route the messages based on the first letter of the customer surname to one of a number of execution groups. One execution group could process letters A-D, the next execution group does E-K and so on.
Lateral thinking can solve this many ways. |
|
| Back to top |
|
|
| Dhiren |
| Posted: Wed Aug 04, 2010 11:41 pm Post subject: |
|
|
Novice
Joined: 27 Jan 2005
Posts: 17
|
Thanks zpat! Much appreciated.
We have actually implemented distribution (0..9) based on the last digit of a product ID , which enables upto 10 threads. But this is implemented for both Batch and RealTime messages making them both throughput at the same capacity.
We are now thinking of parallelising the RealTime ones even further (may be upto 100 using last 2 digits - 00.. 99) and perhaps also serialise the batch to de-prioritize... |
|
| 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
|
|
|
|
