Posted: Mon Dec 07, 2009 7:01 pm Post subject: Aggregation and intermediate queues
Centurion
Joined: 27 Apr 2003 Posts: 124
Dear All,
We have many services fanning out requests to many back end system but in a sequential fashion. We are about to move to Aggregation nodes to make the flow much faster by fanning out requests parallel. But we were worried because of the following reasons,
1)Message traffic is very high in these services, in tune of few millions a day put together by all services. Since Aggregation nodes in turn use SYSTEM.BROKER.AGGR.* queue to services all the request, would it turn out to be a bottle neck and hamper performance? Is there an option to use our own queues instead of SYSTEM.BROKER.AGGR.*?
2)Currently we have couple of services implemented with aggregation nodes. We notice few messages (dated very old) always sit in SYSTEM.BROKER.AGGR.TIMEOT/UNKNOWN queues. Just wonder these messages must be moved out of the queue once the unknown messages timeout occurs, isn’t it?
With Aggregation there is always the worry of a bottleneck scenario and judging by your description everything will be going through a particular flow for the aggregation of the data
To aid this you could separate out the Aggregation into areas of business maybe or even have multiple versions of the running.
I found that using the standard queus initially is fine but if you are going to separate the messages via business area then using your own would be fine as long as all config is geared towards them.
As for old messages all old messages should be analysed and if necessary removed but it depends on what they are. _________________ Who is General Failure and why is he reading my hard drive?
Artificial Intelligence stands no chance against Natural Stupidity.
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