| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| Messages consumed by the app, but are still in the queue |
« View previous topic :: View next topic » |
| Author |
Message
|
| MQMB&WAS |
 Posted: Mon May 15, 2017 3:00 pm Post subject: Messages consumed by the app, but are still in the queue |
 |
|
Centurion
Joined: 12 Jun 2016
Posts: 130
|
Hello Friends,
we had this situation, there's a mainframe job that reads messages off of a queue, we noticed that the job abended for some reason, we tried to rerun it but it stops again without processing any messages from the queue. Later, it was found that the first 2 messages in the queue were actually consumed by the job but are still sitting in the queue and so the job kept failing. After deleting those first 2 messages from the queue, the job ran fine and processed all the remaining messages from the queue.
So, why would the messages sit in the queue even after the job consumed them? Any input is appreciated. Thanks. |
|
| Back to top |
|
 |
| bruce2359 |
| Posted: Mon May 15, 2017 3:08 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
App developers have choices when 'consuming' messages. Besides the usual destructive consume, there's a browse option, where the message remains in the queue. Some apps are written to browse, and if processing is successful, then destructively consume the message.
Why did the app abend?
_________________
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 |
|
|
| MQMB&WAS |
| Posted: Mon May 15, 2017 3:18 pm Post subject: |
|
|
Centurion
Joined: 12 Jun 2016
Posts: 130
|
| bruce2359 wrote: |
App developers have choices when 'consuming' messages. Besides the usual destructive consume, there's a browse option, where the message remains in the queue. Some apps are written to browse, and if processing is successful, then destructively consume the message.
Why did the app abend? |
They say it's because of the 2 duplicate messages(which were already processed).
so, if they chose the 'browse and then consume' option, is there a possibility the job didn't run the 2nd call(consume).?
Also, can we check if the sending application wrote the same messages twice to the queue? The messages are persistent, but are they still available in the MQ logs after the job consumed them(so we can check if they were actually written twice)? |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Mon May 15, 2017 3:47 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
Who are 'they?'
Yes, I've seen badly-written apps MQPUT the same identical message multiple times.
The consuming app is responsible for detecting duplicate messages, and take appropriate action.
I asked you why the app abended. What abend code?
_________________
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 |
|
|
| PaulClarke |
| Posted: Mon May 15, 2017 3:59 pm Post subject: |
|
|
Grand Master
Joined: 17 Nov 2005
Posts: 1002
Location: New Zealand
|
It seems more likely to me that the consuming application is using MQGMO_SYNCPOINT. This means that only if the application commits the transaction or the job ends normally on z/OS will the messages actually be removed from the queue. If the job abends then the messages will be rolled back and be available next time the application runs. This is correct behaviour for MQ.
However, just because messages are rolled back to the queue doesn't mean they weren't processed. It is up to the application to ensure than the transaction integrity is maintained if that is required.
Cheers,
Paul.
_________________
Paul Clarke
MQGem Software
www.mqgem.com |
|
| Back to top |
|
|
| MQMB&WAS |
| Posted: Mon May 15, 2017 4:44 pm Post subject: |
|
|
Centurion
Joined: 12 Jun 2016
Posts: 130
|
| bruce2359 wrote: |
Who are 'they?'
Yes, I've seen badly-written apps MQPUT the same identical message multiple times.
The consuming app is responsible for detecting duplicate messages, and take appropriate action.
I asked you why the app abended. What abend code? |
ABEND 0016 is the code, Bruce. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Mon May 15, 2017 6:39 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
| MQMB&WAS wrote: |
| bruce2359 wrote: |
Who are 'they?'
Yes, I've seen badly-written apps MQPUT the same identical message multiple times.
The consuming app is responsible for detecting duplicate messages, and take appropriate action.
I asked you why the app abended. What abend code? |
ABEND 0016 is the code, Bruce. |
Is this really an abend code? Or, is it a Condition Code/Return Code from a jobstep?
Abend codes come in two flavors, namely: Snnn and Unnn. Snnn are MVS System abend codes; Unnn are user application abend codes. S0c7, for example, is an MVS system abend code - indicating a decimal arithmetic failure.
If the abend is something else, it comes from an application.
Please post the complete abend error message, include the abend code and reason code.
_________________
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 |
|
|
| zpat |
| Posted: Mon May 15, 2017 10:33 pm Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
Worth remembering that MQGMO_SYNCPOINT is the default on z/OS (unlike the other platforms).
If you don't want to conditionally consume the messages, use MQMGO_NOSYNCPOINT.
Browsing messages is generally a bad idea for applications, unless you are an advanced MQ developer and really know what you are doing.
_________________
Well, I don't think there is any question about it. It can only be attributable to human error. This sort of thing has cropped up before, and it has always been due to human error. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Tue May 16, 2017 3:51 pm Post subject: Re: Messages consumed by the app, but are still in the queue |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| MQMB&WAS wrote: |
Hello Friends,
we had this situation, there's a mainframe job that reads messages off of a queue, we noticed that the job abended for some reason, we tried to rerun it but it stops again without processing any messages from the queue. Later, it was found that the first 2 messages in the queue were actually consumed by the job but are still sitting in the queue and so the job kept failing. After deleting those first 2 messages from the queue, the job ran fine and processed all the remaining messages from the queue.
So, why would the messages sit in the queue even after the job consumed them? Any input is appreciated. Thanks. |
You've described a classic poisoned message loop.
1. Get message under syncpoint
2. Attempt to process message.
3. Fail because or problem in message or in app itself.
4. Message rolls back. MQ working as designed.
5. Try again, so back to Step 1. Repeat endlessly.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| gbaddeley |
| Posted: Tue May 16, 2017 6:28 pm Post subject: Re: Messages consumed by the app, but are still in the queue |
|
|
Jedi Knight
Joined: 25 Mar 2003
Posts: 2538
Location: Melbourne, Australia
|
| PeterPotkay wrote: |
You've described a classic poisoned message loop.
1. Get message under syncpoint
2. Attempt to process message.
3. Fail because or problem in message or in app itself.
4. Message rolls back. MQ working as designed.
5. Try again, so back to Step 1. Repeat endlessly. |
Browse the msgs on the queue to check the Backout Count. If its greater than zero, its probably a poisoned msg. The usual action is to investigate why its UOW is being backed out (a failure in the consumer app -- check its logs), and fix it. The poisoned msgs should be moved to another queue for further investigation, so that normal queue processing can continue.
_________________
Glenn |
|
| 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
|
|
|
|
