| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| aggregate timeout but all messages received |
« View previous topic :: View next topic » |
| Author |
Message
|
| pjaffe |
 Posted: Wed Jan 04, 2006 10:35 am Post subject: aggregate timeout but all messages received |
 |
|
Novice
Joined: 03 Sep 2004
Posts: 13
|
I have an aggregation that occasionally (freq. < 1%, volume>500 per day) times out even though all replies were received well within the timeout interval. Any idea why this would occur?
The environment is WBIMB v5 CSD4 running on Windows 2000 advance server. |
|
| Back to top |
|
 |
| JT |
| Posted: Wed Jan 04, 2006 4:16 pm Post subject: |
|
|
Padawan
Joined: 27 Mar 2003
Posts: 1564
Location: Hartford, CT.
|
How do you determine that "all replies were received well within the timeout interval" ?
Do you record a trace event when the fan-out messages arrive on their respective queue(s)? |
|
| Back to top |
|
|
| pjaffe |
| Posted: Thu Jan 05, 2006 6:41 am Post subject: |
|
|
Novice
Joined: 03 Sep 2004
Posts: 13
|
| I have a trace node wired to the timeout terminal on the aggregation node that dumps the messages each time the terminal fires. That is how I know that I have received all of the messages. |
|
| Back to top |
|
|
| x061294 |
| Posted: Thu Jan 05, 2006 11:10 am Post subject: |
|
|
Acolyte
Joined: 05 Apr 2005
Posts: 62
|
So I think you're saying that you have a trace node wired to the timeout terminal, and, when it passes through this node it writes out the message and in the Root.ComIbmAggregateReplyBody.... you see all the replies ? Do you always generate the same number of request messages?
You could look in the BAGGREGATE table and see if there are row's in there for responses that you weren't expecting?
Beyond that, we've never had that type of issue with aggregation. Once the first x number of reply message arrives, the BAGGREGATE is updated, and, once the last arrives, the messages are propagated. I've always wondered if the last reply actually posts to the database first and then all replies are pulled back in, or, if the last reply realizes that it's the last reply and just retrieves the previous replies, but either way it wouldn't matter. We've never seen all the row's in the table associated with one transaction updated but the transaction just waiting. |
|
| Back to top |
|
|
| pjaffe |
| Posted: Thu Jan 05, 2006 11:35 am Post subject: |
|
|
Novice
Joined: 03 Sep 2004
Posts: 13
|
We are dumping the Root.ComIbmAggregateReplyBody tree in the trace node and yes, that is how we are identifying that all replies were received. Each time the transaction is called a fixed number of responses is expected back.
At what point in time would I look for items in the BAGGREGATE table? Just after the timeout or even days later? How would I associate them with the original timeout message? Why would this even cause the timeout to fire? wouldn't it cause the UnknownMessage terminal to fire instead?
I realize that this problem should not be occuring with the given circumstance, but it appears to be and on several brokers all running the same transaction.
Should I open a PMR? |
|
| Back to top |
|
|
| x061294 |
| Posted: Fri Jan 06, 2006 5:09 am Post subject: |
|
|
Acolyte
Joined: 05 Apr 2005
Posts: 62
|
The data in the BAGGREGATE table is created initially from your AggregateRequest node where it writes some basic information about the request message. Then, when the reply comes back, the AggregateReply will update the row in the database with the actual reply message. So if there are 2 replies expected back, you should see (depending on how fast you look and how fast the replies come back) two row's in the database with empty BLOB fields for the data. This is what I was suggesting, is that you could look to see if you were expecting to see 2 row's, but, you see three row's. This would have to be done while waiting for replies. Once the time window has expired, the reply messages that have been received are removed from the database and sent to the timeout terminal.
In order for the flow to propagate to the timeout terminal, there would have needed to be expecting more replies than you got (expecting 3, only received 2). The unknown message terminal is if you're expecting three replies and you get back a message but it doesn't match any of the correlation id's that are logged in the database.
Is there any way for you to log separately how many request messages you've sent out, so, when you get something down the timeout path and you think it has all the replies that you could see if you really did ask for that many, or, if you asked for 1 more than you thought you did?
Is it possible that you're reusing message id's and somehow that's confusing the borker and the synching up of replies?
You certainly can open a PMR and see if they can help point you in some direction. |
|
| 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
|
|
|
|
