| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| Errors during Aggregation Timeout |
« View previous topic :: View next topic » |
| Author |
Message
|
| vk |
 Posted: Thu Nov 01, 2007 9:47 am Post subject: Errors during Aggregation Timeout |
 |
|
Partisan
Joined: 20 Sep 2005
Posts: 302
Location: Houston
|
Hi,
I am using WebSphere Message Broker v6.0.0.5. I am observing some strange behavior during aggregation timeouts. Per documentation, when an aggregation timeout happens, all replies which were received within the timeout interval should be propagated to the Timeout terminal of the AggregateReply node. I have compute nodes in my flow to handle timeout messages, but nothing is sent to the Timeout terminal during aggregation timeouts.
Whenever a timeout happens, the following error is recorded in the trace and logs -
| Quote: |
RecoverableException BIP4424E: Unable to retrieve control message in AggregateReply node. Queue=''SYSTEM.BROKER.AGGR.TIMEOUT'', Reason Code='2026'.
The AggregateReply node failed to retrieve a control message. This message is used by the node to control a particular aggregation. It is used both for normal processing and for timeout processing. Failed to get a message from queue ''SYSTEM.BROKER.AGGR.TIMEOUT'' because of WebSphere MQ reason code '2026'. Check that the underlying aggregation WebSphere MQ queue is functioning correctly. |
Has anyone seen this error? I do not see any issues with the SYSTEM.BROKER.AGGR.* queues. Also, I do not face any issues in cases where there is no timeout. Messages are getting propagated to the Out terminal of the AggregateReply node and further processing also gets completed successfully.
Whenever a timeout happens, following is the status of messages in the SYSTEM.BROKER.AGGR.* queues -
| Quote: |
SYSTEM.BROKER.AGGR.CONTROL - Control message is removed from this queue
SYSTEM.BROKER.AGGR.REPLY - All replies which were received before timeout interval are retained in this queue. The queue is not cleared.
SYSTEM.BROKER.AGGR.REQUEST - All requests which did not receive a corresponding reply within the timeout interval are retained in this queue. The queue is not cleared
SYSTEM.BROKER.AGGR.TIMEOUT - A message is put into the timeout queue whenever a timeout happens |
The SYSTEM.BROKER.AGGR.REQUEST and SYSTEM.BROKER.AGGR.REPLY queues are cleared only when the aggregation completes successfully and a message containing all replies is propagated to the Out terminal of the AggregateReply node. In all other cases, messages remain in the queues and I am having to manually delete them during timeouts. Is this the expected behavior?
Thanks in advance,
VK. |
|
| Back to top |
|
 |
| jefflowrey |
| Posted: Thu Nov 01, 2007 9:52 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
I would open a PMR.
2026 implies that the message on the TIMEOUT queue is badly formed or that something has gone very wrong in the AggregateReply node internal coding.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| vk |
| Posted: Thu Nov 01, 2007 12:07 pm Post subject: |
|
|
Partisan
Joined: 20 Sep 2005
Posts: 302
Location: Houston
|
Thanks Jeff. I too was planning to open a PMR with IBM. But just wanted to check if someone else had faced this issue.
I had one more question regarding aggregation. When does the SYSTEM.BROKER.AGGR.REQUEST and SYSTEM.BROKER.AGGR.REPLY queues get cleared? Do they get cleared when a timeout happens or do they get cleared only when aggregation is successful and a message is propagated through the Out terminal of the AggregateReply node?
I guess the queues should get cleared during a timeout also because the request and reply messages for that aggregation should be of no use to the broker after a timeout.
Ever since moving to MB 6.0, I have been facing issues with aggregation timeouts. I am not sure whether this is an issue with the broker or whether it is an issue in my flow. But my flow used to work fine and handle timeouts correctly in WMQI v2.1. Only change I did after moving to MB6 was to remove the logic to pass a control message from the fan-out flow to the fan-in flow.
Thanks,
VK. |
|
| Back to top |
|
|
| vk |
| Posted: Tue Nov 06, 2007 7:33 am Post subject: |
|
|
Partisan
Joined: 20 Sep 2005
Posts: 302
Location: Houston
|
I raised a PMR with IBM for this issue. This is a defect in the message broker while handling aggregation timeouts (APAR IC51825). Please check the below link for more details - http://www-1.ibm.com/support/docview.wss?uid=swg1IC51825
The fix for this issue would be included in fixpack 6 for the message broker. Meanwhile, IBM has a patch which can be applied on 6.0.0.5 version of the message broker to correct this issue.
Regards,
VK. |
|
| Back to top |
|
|
| Tasse |
| Posted: Fri Nov 09, 2007 6:44 am Post subject: |
|
|
Newbie
Joined: 09 Nov 2007
Posts: 2
|
We had the same problem with version 6.0.0.1. The aggregation mechanism couldn't handle more than 24 simultaneous requests in an aggregation, which we could verify with a a couple of simple message flows. The first one took the number of request in the aggregation as parameter to the message flow which then created that many requests in the aggregation to the second message flow. The second flow was a dummy flow that just sent the request back as a reply. As we came upp to 25 request, the broker went nuts!
We raised a PMR for the issue and sent out test flows to IBM, and received a customer specific fixpack that solved the problem. Unfortunately, the problem reappeared in version 6.0.0.5, since the fix was not introduced in the ordinary release. Just a few weeks ago we receiced the fix for 6.0.0.5 so we could upgrade our production system to that release, and all is well again.
Regards
Tasse |
|
| 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
|
|
|
|
