| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| damaged queue, circular logging and missing messages |
« View previous topic :: View next topic » |
| Author |
Message
|
| zrux |
 Posted: Sat Dec 18, 2021 10:29 am Post subject: damaged queue, circular logging and missing messages |
 |
|
Apprentice
Joined: 21 May 2006
Posts: 37
Location: UK
|
Hello
Any way we can recover messages being sent to a local Q which got damaged.
The system was having circular logging configured and one QM lets say QMA was trying to send messages to QMB local Queue.
The object damage error was recovered after we failed over the QMB from node 1 to node2 automatically. The messages being sent were persistent messages and queue was persistent.
Question is- after the error condition was recovered, is there a way to recover the messages that was trying to go to the queue when the queue object was damaged given that this was circular logging |
|
| Back to top |
|
 |
| exerk |
| Posted: Sun Dec 19, 2021 8:18 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
The following is my understanding of what should happen, but in all honesty I don't know what happens to persistent messages from an external source that cannot be committed to the target queue or put to the DLQ in this scenario: Logically I would expect them to be 'rejected', so I'm not sure there would be any 'recovery' as such. I'm sure that someone with greater knowledge of the internal workings will be along to put us both straight.
And a nit-pick I know, but "...The messages being sent were persistent messages and queue was persistent..." - QUEUES are neither persistent or non-persistent, only the messages on them. The persistence setting on a queue is only a 'placeholder' for programmers to lazy to set it in code, can be over-ridden in by an application anyway, and if relying on the queue setting then today's persistent messages could be tomorrow's non-persistent messages if someone changes the queue attribute.
And lastly, with the in-built automatic log management and ability to migrate between the logging types available to queue managers (version dependent) there is little reason to use circular logging to reduce management overhead anymore.
_________________
It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Sun Dec 19, 2021 9:25 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9396
Location: US: west coast, almost. Otherwise, enroute.
|
IF the message was persistent, AND the log file still exists (has not been overwritten), AND you can identify the message in the log file, AND ...
Quicker, and a better practice, would be to delete and redefine the damaged queue object, then re-drive the app transaction that created the message in the first place.
"Persistent queues" are an abstraction in JMS development environment. As exerk pointed out, messages may be either persistent or non-persistent. The app should specify persistence in the MQMD ahead of each MQPUT.
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| zrux |
| Posted: Sun Dec 19, 2021 11:33 pm Post subject: |
|
|
Apprentice
Joined: 21 May 2006
Posts: 37
Location: UK
|
If the message was persistent, how do MQ behave...if the Object was damaged - where would it write the messages?
I didnt see anything going to the DLQ neither waiting on the XMITQ Queue of QMA trying to go to QMB |
|
| Back to top |
|
|
| hughson |
| Posted: Mon Dec 20, 2021 3:03 am Post subject: |
|
|
Padawan
Joined: 09 May 2013
Posts: 1914
Location: Bay of Plenty, New Zealand
|
| zrux wrote: |
| If the message was persistent, how do MQ behave...if the Object was damaged - where would it write the messages? |
If you're asking what would happen if an application attempted to do an MQPUT of a message to a queue that was already damaged, then the answer is that the MQPUT call would fail with the reason code MQRC_OBJECT_DAMAGED (2101)
So your application should handle the error, just as it might handle something like MQRC_Q_FULL. In this situation, the message was never successfully put, so never existed. It will not be on a DLQ or an XMITQ.
Others have already answered what happens to the messages put to the queue which was subsequently damaged.
Cheers,
Morag
_________________
Morag Hughson @MoragHughson
IBM MQ Technical Education Specialist
Get your IBM MQ training here!
MQGem Software |
|
| Back to top |
|
|
| exerk |
| Posted: Mon Dec 20, 2021 3:32 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| hughson wrote: |
| ...It will not be on a DLQ or an XMITQ... |
Question: What about messages coming from another queue manager? Will they be 'rejected' back to the sending queue manager, or go to the DLQ as they can't be put to the damaged object?
_________________
It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys. |
|
| Back to top |
|
|
| Andyh |
| Posted: Mon Dec 20, 2021 9:55 am Post subject: |
|
|
Master
Joined: 29 Jul 2010
Posts: 237
|
A damaged queue indicates some inconsistency in the queue state.
Each queue has a disk image and a memory image, a damaged queue might represent a problem in either (or both) the memory or the disk image.
You initial append appears to indicate that a failover resolved the damage.
A failover causes the memory image to be rebuilt from the disk image, which therefore suggests the problem was limited to the memory image.
The failover will have caused all of the non-persistent messages (if any) to be lost, but there should be no loss of integrity w.r.t the persistent state.
Similarly the persistent state should be consistent w.r.t the persistent state of connected queue manager.
All of the above needs a caveat that a damaged object typically indicates some APARable error (particularly if the issue is limited to the memory image of the queue). |
|
| Back to top |
|
|
| hughson |
| Posted: Mon Dec 20, 2021 1:26 pm Post subject: |
|
|
Padawan
Joined: 09 May 2013
Posts: 1914
Location: Bay of Plenty, New Zealand
|
| exerk wrote: |
| hughson wrote: |
| ...It will not be on a DLQ or an XMITQ... |
Question: What about messages coming from another queue manager? Will they be 'rejected' back to the sending queue manager, or go to the DLQ as they can't be put to the damaged object? |
That would not be an application putting to a damaged queue. If a channel is putting to a damaged queue then it will follow its usual error path which might roll back ot might put on DLQ depending on how that system is configured.
_________________
Morag Hughson @MoragHughson
IBM MQ Technical Education Specialist
Get your IBM MQ training here!
MQGem Software |
|
| 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
|
|
|
|
