| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| Inner Workings of v5 Aggregation Nodes |
« View previous topic :: View next topic » |
| Author |
Message
|
| bbakerman |
 Posted: Mon Aug 16, 2004 8:51 pm Post subject: Inner Workings of v5 Aggregation Nodes |
 |
|
Apprentice
Joined: 17 Dec 2003
Posts: 41
|
Can an WMQI expert please explain the inner workings of the Aggregation nodes and specifically whether they provide "internal database queueing" of messages?
As a team we are deciding whether to use aggregation nodes or use a custom "getwait" node that "waits" for specific reply to come back.
The v5 doco says about the Aggregation Reply node that :
| Quote: |
"The AggregateReply node receives the inbound responses from the input node through its in terminal. Each reply message received by the AggregateReply node is stored persistently in the broker database.
When all of the replies for a particular group of aggregation requests have been collected, the AggregateReply node creates an aggregated reply message and propagates this through the out terminal.
|
So I assume that if there are multiple message flow instances in an execution group (or even multiple execution groups with the same flow) that the AggReply node will "queue" any reply messages it encounters, even if they are really for another instance of the flow.
Hence the "throughput" will be higher than a "straight" get wait flow design because work is being done (ie the reply queue is being services) by all instances of the AggReply nodes even if the replies are not for them.
Also can some one please explain how the "timeout" on the aggReply nodes actually works and specifically how it decides what an "unkown message" is, especially if it really is DB queueing replies that it encouters.
The doco says :
| Quote: |
| Optional: set a value for the Unknown Message Timeout if you want to retain an unrecognized message before propagating it to the unknown terminal. |
I would assume that an unknown message means a reply for which this instance of the AggReply node is not looking for. However I assume it may be a reply to another outstanding AggRequest and hence should not be propogated down the unknow terminal by the AggReply node too easily. |
|
| Back to top |
|
 |
| fjcarretero |
| Posted: Tue Aug 17, 2004 7:58 am Post subject: |
|
|
Voyager
Joined: 13 Oct 2003
Posts: 88
|
| Quote: |
| So I assume that if there are multiple message flow instances in an execution group (or even multiple execution groups with the same flow) that the AggReply node will "queue" any reply messages it encounters, even if they are really for another instance of the flow |
You're right!.
In the aggRequest, you can set up the timeout. This means that the aggReply is only going to wait that amount of time for the replies to return.
If after that period of time, any of the replies has not arrived, the message is propagated through the timeout terminal.
Imagine that one second later, the reply that the aggReply was waiting for arrives 1 second later than the timeout period. Then that reply will be propagated through the unknown terminal.
Hope this helps!.
Regards
Felipe |
|
| Back to top |
|
|
| bbakerman |
| Posted: Tue Aug 17, 2004 7:12 pm Post subject: |
|
|
Apprentice
Joined: 17 Dec 2003
Posts: 41
|
| Quote: |
If after that period of time, any of the replies has not arrived, the message is propagated through the timeout terminal.
Imagine that one second later, the reply that the aggReply was waiting for arrives 1 second later than the timeout period. Then that reply will be propagated through the unknown terminal.
|
But if there is mutliple instances of a message flow, then one of the other Agg Fan In flows may pick up the late message. How can the AggReply node "know" that a message is unknown when it has already propogated down the timeout terminal and how can it know it was bound for it and not another AggReply instance? |
|
| Back to top |
|
|
| solomita |
| Posted: Thu Sep 23, 2004 7:28 am Post subject: |
|
|
Voyager
Joined: 06 May 2003
Posts: 94
|
| Quote: |
So I assume that if there are multiple message flow instances in an execution group (or even multiple execution groups with the same flow) that the AggReply node will "queue" any reply messages it encounters, even if they are really for another instance of the flow
You're right!. |
So if you have an aggregation flow that is deployed to multiple execution groups within a single broker, that is valid and will work? It currently is working at our site but someone stated that either it was not best practice or that it should not be done because replies wont necessarily match up properly.
_________________
IBM Certified Specialist - WebSphere MQ Integrator
IBM Certified System Administrator - WebSphere MQ V5.3
IBM Certified System Administrator - WebSphere Business Integration Message Broker V5 |
|
| 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
|
|
|
|
