| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| How to handle recovery w/ Persistant queues? |
« View previous topic :: View next topic » |
| Author |
Message
|
| pilotError |
 Posted: Fri Apr 26, 2002 10:32 am Post subject: |
 |
|
Newbie
Joined: 18 Apr 2002
Posts: 4
|
This is probably a general question, but how do people handle recovery so you don't end up reading the same messages repeatedly?
I have a workable program that sends data through an outbound queue, and receives confirmations via an inbound queue, which is read by a reader thread and inserted into a database.
The reader thread reads all messages in the queue using get options:
getMsgOpt.options = getMsgOpt.options + MQC.MQGMO_SYNCPOINT;
getMsgOpt.options = getMsgOpt.options + MQC.MQGMO_WAIT; getMsgOpt.options = getMsgOpt.options + MQC.MQGMO_FAIL_IF_QUIESCING;
getMsgOpt.matchOptions = MQC.MQMO_NONE;
getMsgOpt.waitInterval = MQC.MQWI_UNLIMITED;
If the thread dies, how can I set it up that it starts browsing at the last message I processed successfully?
P.S. I now have 2 days MQ Experience!
Seriously, should I get rid of the persistance on the queue definition?
Thanks in advance for any help you can provide!
Mike... |
|
| Back to top |
|
 |
| kolban |
| Posted: Fri Apr 26, 2002 4:13 pm Post subject: |
|
|
Grand Master
Joined: 22 May 2001
Posts: 1072
Location: Fort Worth, TX, USA
|
Message persistence is a function of the lifetime of the message is the queue manager itself fails. Persistent messages will survive a queue manager failure and non-persistent messages will be lost. Persistence is not a function of message recovery when an application fails.
Your answer is about message syncpointing. When you get a message under syncpoint, the message is not fully/truly removed from the queue until the application either disconnects cleanly or else commits the previous work activities. What this means is that if you get a message with syncpoint and, prior to processing it sucessfully, the thread/app crashes, the message will be put back to the queue and will be eligible to be re-read as the next message obtained.
Your code looks good. No need to "add" options together, simply "or" them together in one assignment. Nothing wrong with what you are doing, just personal preference of coding styles. |
|
| Back to top |
|
|
| deneb |
| Posted: Fri Apr 26, 2002 4:20 pm Post subject: |
|
|
Novice
Joined: 15 Apr 2002
Posts: 18
|
Hi
GrandMaster Kilban has answered you to the point. However, to improve your experience there are a few terms that would be handy to know
- BackOut Count
- Backout Threshold
- Backout Queue
if the message is read and backedout then the backout coulnt increases. the moment the message reaches the backout threshold QMgr discards it on your own.
This is the answer to the 1st question.
deneb
|
|
| Back to top |
|
|
| StefanSievert |
| Posted: Mon Apr 29, 2002 9:44 am Post subject: |
|
|
Partisan
Joined: 28 Oct 2001
Posts: 333
Location: San Francisco
|
| Quote: |
On 2002-04-26 17:20, deneb wrote:
Hi
GrandMaster Kilban has answered you to the point. However, to improve your experience there are a few terms that would be handy to know
- BackOut Count
- Backout Threshold
- Backout Queue
if the message is read and backedout then the backout coulnt increases. the moment the message reaches the backout threshold QMgr discards it on your own.
This is the answer to the 1st question.
deneb
|
Deneb,
your hint to the poison message loop problem is a very valuable one. However, I am afraid that your statement is not quite correct. The queue manager will not discard any messages based on these values. These local queue attributes are solely for the purpose of enabling application code to detect, if a message has suffered from a certain number (mqmd.BackoutCount) of backouts. The application can then MQINQ about the Threshold and RequeueQueue values and move the message to a different queue, so that the normal processing of the queue can continue.
Again, this has to be coded in your application and is not done by the queue manager itself.
See the application programming guide for more details about using these values.
Cheers,
Stefan
_________________
Stefan Sievert
IBM Certified * WebSphere MQ |
|
| Back to top |
|
|
| pilotError |
| Posted: Mon Apr 29, 2002 12:54 pm Post subject: |
|
|
Newbie
Joined: 18 Apr 2002
Posts: 4
|
Hi,
Thanks for the replies, I have a little better understanding of the situation. I didn't code for the re-starts, but thanks for the tips.
If I open the queue for MQC.MQOO_INPUT_SHARED | MQC.MQOO_FAIL_IF_QUIESCING, would this be the reason the code "sees" the messages I already read? It seems to keep re-reading messages I already processed. I do a qMgr.commit() after I have read and processed the row successfully.
I ran into this while building a simulator. Basically the code reads the outbound queue enhances the message and writes it to my inbound queue, to simulate an external system that I don't have access to in development. Everytime I restart this simulator, it re-reads all the messages in the outbound queue.
Hmmm, I noticed I use the same (private MQQueueManager qMgr) to open both the input and output queues. Could that be the problem??? |
|
| 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
|
|
|
|
