| Author |
Message
|
| vennela |
 Posted: Thu Feb 23, 2006 9:33 pm Post subject: Aggregate flows behaviour |
 |
|
Jedi Knight
Joined: 11 Aug 2002
Posts: 4055
Location: Hyderabad, India
|
I have an aggregate flow that looks like this.
MQInput -> AggregateControl -> Compute -> MQOutput -> AggregateRequest
MQInput -> AggregateReply -> Compute1 -> MQOutput
If I put three simultaneous requests, the replies from the are all being aggregated sent back as one reply.
Let me say that in other words.
I put one Request (fanned out as 3 requests) ---> I didn't get any response
I put another request (fanned out as 3 requests) ----> I got the response but this time I had the results of all the 6 individual requests.
Is there anything special we have to do in the broker ....... |
|
| Back to top |
|
 |
| vennela |
| Posted: Fri Feb 24, 2006 12:04 am Post subject: |
|
|
Jedi Knight
Joined: 11 Aug 2002
Posts: 4055
Location: Hyderabad, India
|
OK
I did some more testing and I found this.
I give one input and is fanned out as two requests say R1 and R2
I give another input and is fanned out as two requests say R3 and R4
Now the processing application processes R1 R3 and R4 leaving R2
As soon as I process R1 and R3, I get the reply to my first flow.
Is this how it is supposed to work. I have a strong feeling that it is a bug in the product unless somebody tells me I am doing something wrong. |
|
| Back to top |
|
|
| nathanw |
| Posted: Fri Feb 24, 2006 3:07 am Post subject: |
|
|
Knight
Joined: 14 Jul 2004
Posts: 550
|
definitely not how it should be working
each response is geared to each request never mind the amount of fanning the only thing that will stop a response is a timeout or an error
unless you have coded the responses to be concatenated together
check your config on the responses
are you using control nodes?
etc |
|
| Back to top |
|
|
| vennela |
| Posted: Fri Feb 24, 2006 5:19 am Post subject: |
|
|
Jedi Knight
Joined: 11 Aug 2002
Posts: 4055
Location: Hyderabad, India
|
| Quote: |
| are you using control nodes? |
Control terminals are deprecated in v6 and I am leaving them unwired. |
|
| Back to top |
|
|
| nathanw |
| Posted: Fri Feb 24, 2006 5:41 am Post subject: |
|
|
Knight
Joined: 14 Jul 2004
Posts: 550
|
apologies did not realise you were on V6
but my thoughts still apply UNLESS they have changed the beavious of Aggregation so much
anychance yu can add a screen shot of yur flows? |
|
| Back to top |
|
|
| wschutz |
| Posted: Fri Feb 24, 2006 6:45 am Post subject: |
|
|
Jedi Knight
Joined: 02 Jun 2005
Posts: 3316
Location: IBM (retired)
|
ven, can you give a little more detail...I'm confused because in one post you say:
| Quote: |
I put one Request (fanned out as 3 requests) ---> I didn't get any response
I put another request (fanned out as 3 requests) ----> I got the response but this time I had the results of all the 6 individual requests.
|
so it sounds like no response for three "request" messages, but on the other hand....
| Quote: |
I give one input and is fanned out as two requests say R1 and R2
I give another input and is fanned out as two requests say R3 and R4
Now the processing application processes R1 R3 and R4 leaving R2
As soon as I process R1 and R3, I get the reply to my first flow. |
So, is the problem that you "never" get anything back from the first executaion thread until the second one runs and sends out request messages, or sometimes you do? sorry, I'm just trying to understand ....
_________________
-wayne |
|
| Back to top |
|
|
| vennela |
| Posted: Fri Feb 24, 2006 8:15 am Post subject: |
|
|
Jedi Knight
Joined: 11 Aug 2002
Posts: 4055
Location: Hyderabad, India
|
| Quote: |
| So, is the problem that you "never" get anything back from the first executaion thread until the second one runs and sends out request messages, or sometimes you do? sorry, I'm just trying to understand .... |
Sometimes, if I put a request it works just fine.
When I put two requests at a time that's when I am having problem.
Let's forget about the first case for now.
Consider this case
| Quote: |
OK
I did some more testing and I found this.
I give one input and is fanned out as two requests say R1 and R2
I give another input and is fanned out as two requests say R3 and R4
Now the processing application processes R1 R3 and R4 leaving R2
As soon as I process R1 and R3, I get the reply to my first flow.
Is this how it is supposed to work. I have a strong feeling that it is a bug in the product unless somebody tells me I am doing something wrong. |
Is the above behaviour expected? |
|
| Back to top |
|
|
| nathanw |
| Posted: Mon Feb 27, 2006 12:40 am Post subject: |
|
|
Knight
Joined: 14 Jul 2004
Posts: 550
|
ok by default each message going through aggregation is given a unique identifier
what you are saying is that if one message comes through it works fine but multiples do not
to me that sounds like the set up is incorrect in one of your nodes to give each item a unique value
you state that you have not connected your control terminals etc but I think that may be the case as if you are using separate flows to handle your aggregation then a control message is normally required unless V6 is different.
Have you tried merging the 2 flows together? |
|
| Back to top |
|
|
| vennela |
| Posted: Mon Feb 27, 2006 8:38 am Post subject: |
|
|
Jedi Knight
Joined: 11 Aug 2002
Posts: 4055
Location: Hyderabad, India
|
| nathanw wrote: |
| ok by default each message going through aggregation is given a unique identifier ? |
Should I be giving the uniqueId or will broker do it.
| nathanw wrote: |
| Have you tried merging the 2 flows together |
They are in the same flow except that the control terminals are unwired.
Also, in some other post I saw that there would be an entry in BAGGREGATE table in the broker database, but I found the table empty. |
|
| Back to top |
|
|
| wschutz |
| Posted: Mon Feb 27, 2006 8:47 am Post subject: |
|
|
Jedi Knight
Joined: 02 Jun 2005
Posts: 3316
Location: IBM (retired)
|
Venella, did you try and run the provided aggregation sample flows and see if you have the same problem with them? That would help narrow down the problem to either your flow or the broker itself.....
_________________
-wayne |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Mon Feb 27, 2006 8:50 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
The Aggregate nodes in v6 are using an MQ store rather than a database store for aggregation. So you won't likely see something in BAGGREGATE.
I don't believe that it's changed that each aggregate request needs it's own unique msg id so that it can be tracked on the reply. So just set the flag to create a new id on the MQOutput node.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| Ian |
| Posted: Mon Feb 27, 2006 9:10 am Post subject: |
|
|
Disciple
Joined: 22 Nov 2002
Posts: 152
Location: London, UK
|
Yes, v6 uses MQ storage for aggregation and therefore the BAGGREATE tables are redundant/deprecated.
Refer to the v6 help under topic "ab00025_" which covers "What's new in Version 6.0?"
Improved performance and scalability
Performance of the broker runtime has been significantly improved by the following enhancements:
- The aggregation nodes now use WebSphere MQ queues to store state information instead of a database. This improves the throughput of all requests, with the greatest improvement being gained with non-persistent requests.
In terms of your actual problem, it sounds like you need to open a PMR and provide the support team with your flow and traces so that they can have a closer look.
_________________
Regards, Ian |
|
| Back to top |
|
|
| vennela |
| Posted: Mon Feb 27, 2006 9:38 am Post subject: |
|
|
Jedi Knight
Joined: 11 Aug 2002
Posts: 4055
Location: Hyderabad, India
|
| Quote: |
| I don't believe that it's changed that each aggregate request needs it's own unique msg id so that it can be tracked on the reply. So just set the flag to create a new id on the MQOutput node. |
OK, so this might be the problem.
I have left the New Message filed unchecked. While reading the documentation, I read after the AggregateTerminal, environment should not be changed, so I took that the MessageId field should be unchecked. So, I am doing this wrong I guess.
I'll see by changing it if everything goes fine. |
|
| Back to top |
|
|
| nathanw |
| Posted: Tue Feb 28, 2006 3:19 am Post subject: |
|
|
Knight
Joined: 14 Jul 2004
Posts: 550
|
In the Mqoutput node prior to Aggregate Request the Advanced screen should have New Message Id checked and Message context set to Pass All
This is in V5 but I found that if I set these then multiple messages ran through fine |
|
| Back to top |
|
|
| vennela |
| Posted: Wed Mar 01, 2006 10:31 am Post subject: |
|
|
Jedi Knight
Joined: 11 Aug 2002
Posts: 4055
Location: Hyderabad, India
|
| nathanw wrote: |
In the Mqoutput node prior to Aggregate Request the Advanced screen should have New Message Id checked and Message context set to Pass All
This is in V5 but I found that if I set these then multiple messages ran through fine |
I checked the New Message Id and set the context to Set All.
It still didn't work. |
|
| Back to top |
|
|
|
|
