| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| Best practice for Recycle of Backout Q to Input Q? |
« View previous topic :: View next topic » |
| Author |
Message
|
| zz348 |
 Posted: Mon Dec 09, 2013 7:12 am Post subject: Best practice for Recycle of Backout Q to Input Q? |
 |
|
Newbie
Joined: 04 Jun 2012
Posts: 8
|
We are in a clustered MB 8.x and MQ 7.1 environment using backout queues and backout thresholds. Searched for this subject under "backout" and "recycle" but didn't see any good answers. Apologies if I missed a previous posting.
What is the most common best practice for Admin recycling messages from the backout queue to the input queue, when the dependent systems that caused the issue are back up and healthy?
There is debate on our team on whether the Admins should use a "Q" support pac utility, or whether development team should create a java program to programmatically and transactionally read from BO Q and put to Input Q. This seems inefficient as the Websphere based java program would need access to every Q Manager we have to be reusable, and would be about like an Oracle DBA asking us to query, insert, delete one row at a time to move a table.
What do the thousands of MQ Admins throughout the world managing BO queues do as a typical best practice to recycle to Input Queue? |
|
| Back to top |
|
 |
| Vitor |
| Posted: Mon Dec 09, 2013 7:24 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
IMHO writing something for this involves reinventing the wheel. There are various support pacs which can perform this, including the rather odd and inefficent UoW scenario you describe, so I'm not sure what value such a Java program would add.
<plug> not allowed's IR 360 tool and other commercial solutions also provide such functionality, often in a convienient web-browser based form</plug>
IMHO the key issue here is deciding & communicating when the consuming system is "healthy", and not just that the application team want to run the messages through again in case the magic has come back.
Note also that you need to cater for the scenario where the messages are on the backout queue because they genuinely have a problem which prevents them from being posted (mandatory XML tag not being supplied by sending system for example).
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| 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
|
|
|
|
