| Author |
Message
|
| cb |
 Posted: Thu Aug 11, 2005 2:23 am Post subject: Aggregation in multiple instances |
 |
|
Newbie
Joined: 11 Aug 2005
Posts: 2
|
Hello,
I looking into the possibilities of deploying an aggregation message flow several times in order to process messages in parallel.
Has anyone actually used aggregation flows:
a) multi-threaded (deployed with the "additional instances" parameter)
b) in multiple execution groups on the same broker
c) on different brokers listening to shared queues of an MQ Cluster
I am worried that the different instances might get confused with the response messages received in the input node of the fan-in part of the flow. What happens if instance2 of the aggr_flow receives a message that belongs to the aggregation of instance1. Will they block each other?
Thanks a lot for your help!
Btw ( I am talking about MB v5 on MQ 5.3)
_________________
Best Regards
Carsten |
|
| Back to top |
|
 |
| TonyD |
| Posted: Thu Aug 11, 2005 2:54 pm Post subject: |
|
|
Knight
Joined: 15 May 2001
Posts: 540
Location: New Zealand
|
a) Yes
b) Yes
c) Yes
They won't get mixed up....aggregation management is based on matching fan-out message ids with fan-in correlation ids, using temporary entries in the BAGGREGATE table. |
|
| Back to top |
|
|
| cb |
| Posted: Fri Aug 12, 2005 12:11 am Post subject: |
|
|
Newbie
Joined: 11 Aug 2005
Posts: 2
|
| TonyD wrote: |
a) Yes
b) Yes
c) Yes
They won't get mixed up....aggregation management is based on matching fan-out message ids with fan-in correlation ids, using temporary entries in the BAGGREGATE table. |
Thanks for your reply.
I can see that the broker might internally match responses for different instances of a flow based on the database.
But what happens when I have 2 brokers with a database/ BAGGREGATE table each (the cluster scenario as in c) ). Does the AggregateReply node put the message back on the queue when it discovers that it was meant for the other broker? For that matter how would the AggregationFlow in broker1 know that the response it just picked up belongs to an aggregation on broker2 and is not an unknown response?
_________________
Best Regards
Carsten |
|
| Back to top |
|
|
| JULLRICH |
| Posted: Sat Aug 13, 2005 5:35 am Post subject: |
|
|
Apprentice
Joined: 11 Aug 2005
Posts: 42
Location: München
|
Hi,
I'm afraid that this not works - two brokers.
Try the following:
connect on every flow a second InputNode for replys! ... so you have 3 ReplyInputQueues ...
One for both flow and queueA for Flow A und queueB for flow B!
Connect on each AggregateReply (Terminal Unknown) a Filter or ComputeNode that says if it is an reply for the other flow or not. Then connect there an OutputNode. In Flow A use queue B and in Flow B use queueA ...
Or use DestinationList for more than two Brokers and build/get the queuenames inside of the flow.
It's only an makeshift!!!
Regards
Jens |
|
| Back to top |
|
|
| EddieA |
| Posted: Sat Aug 13, 2005 8:55 am Post subject: |
|
|
Jedi
Joined: 28 Jun 2001
Posts: 2453
Location: Los Angeles
|
| Quote: |
| I'm afraid that this not works - two brokers. |
Why not.
| Quote: |
| But what happens when I have 2 brokers with a database/ BAGGREGATE table each (the cluster scenario as in c) |
As long as the application that services the message follows "normal" MQ conventions, and uses the ReplyToQueue/QueueManager from the request message, then the reply will always go back to the correct broker.
Cheers,
_________________
Eddie Atherton
IBM Certified Solution Developer - WebSphere Message Broker V6.1
IBM Certified Solution Developer - WebSphere Message Broker V7.0 |
|
| Back to top |
|
|
| JULLRICH |
| Posted: Sat Aug 13, 2005 10:05 pm Post subject: |
|
|
Apprentice
Joined: 11 Aug 2005
Posts: 42
Location: München
|
Oh  ... thats correct!!!
So you don't need my 'solution'*g |
|
| Back to top |
|
|
|
|
