| Author |
Message
|
| tisged |
 Posted: Fri Oct 22, 2010 12:13 am Post subject: MQ Error 2003 then duplicated messages |
 |
|
Newbie
Joined: 22 Oct 2010
Posts: 6
|
Can anyone help please? Recently upgraded from MQ5 to MQ7 on AIX. After 5 days we got an error 2003 'MQRC backed out', which is usually due to being unable to save a message in the log files. After recovering from this, we experienced lots of previously processed messages coming through again. Can anyone explain this and tell me how we prevent this happening?  |
|
| Back to top |
|
 |
| Mr Butcher |
| Posted: Fri Oct 22, 2010 1:16 am Post subject: |
|
|
Padawan
Joined: 23 May 2005
Posts: 1716
|
| Quote: |
| which is usually due to being unable to save a message in the log files |
this is just a guess. investigate for the real reason. if Mq was short on log space there should be an entry in the log files about that,.
| Quote: |
| After recovering from this |
exactly - what actions have been performed for recovery?
IMHO, if a message was backed out, there is no need for a further recovery. what has to be done is to find the problem and fix it. then retry.
maybe the application is not working properly and is retrying too much.
_________________
Regards, Butcher |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Fri Oct 22, 2010 6:56 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9472
Location: US: west coast, almost. Otherwise, enroute.
|
| Quote: |
| After recovering from this, we experienced lots of previously processed messages coming through again. |
On an MQCMIT or MQDISC call, when the commit operation has failed and the unit of work has been backed out. All resources that participated in the unit of work have been returned to their state at the start of the unit of work. The MQCMIT or MQDISC call completes with MQCC_WARNING in this case.
So, when a message is backed out, it is restored to the queue from where it was consumed.
If the consuming application is triggered again, it will mqget the same message that was most recently backed out. The message is not duplicated.
If the back-end work (like a DB update) is NOT included in the unit of work, then you would likely see the symptom of "multiple occurrences" of the same message that has already been processed.
[edit]
This is an application coding error.
| Quote: |
| which is usually due to being unable to save a message in the log files |
If there was insufficient log space, the application would have received a ReasonCode to that effect.
_________________
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 |
|
|
| PeterPotkay |
| Posted: Fri Oct 22, 2010 8:58 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
And it could be a non triggered app to.
The app waits on the queue, getting messages as they arrive. It uses syncpoint for all the gets, but never commits. But it processes the data in the messages as it gets them. Eventually the logs fill, everything rolls back, and the app starts getting the same messages again.
Like Johnnie would have said if this app was on trial - "If the syncpoint fits, you must commit!" (or backout if appropriate).
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| tisged |
| Posted: Mon Oct 25, 2010 9:37 am Post subject: |
|
|
Newbie
Joined: 22 Oct 2010
Posts: 6
|
Thanks very helpfull
answers:
q: was it short on space?
a: Yep, same size as pre upgrade but log files filled in 4 days
q: what action taken?
a: stpped/restarted cobol 'readers' |
|
| Back to top |
|
|
| tisged |
| Posted: Mon Oct 25, 2010 9:39 am Post subject: |
|
|
Newbie
Joined: 22 Oct 2010
Posts: 6
|
can you tell me then if anything need to consder re comit/rollback when upgrading from 5.3 to 7.1?
we just recompiled, minor changes, retested links. We did not change any procedures or commands but suspect our syncpoints are now not where we expect them, or are there any configuration settings which may impact syncpoints? |
|
| Back to top |
|
|
| Vitor |
| Posted: Mon Oct 25, 2010 9:42 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| tisged wrote: |
| a: Yep, same size as pre upgrade but log files filled in 4 days |
To repeat a question asked above: how do you know the log was full? I accept that's the example given in the InfoCenter for a 2003 but how do you know that's the situation here? In common with previous posters I'd have expected other messages & reason codes if the logs were full & indeed as they came close to capacity.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| tisged |
| Posted: Tue Nov 02, 2010 12:56 am Post subject: |
|
|
Newbie
Joined: 22 Oct 2010
Posts: 6
|
| issue resolved, application error found whereby the mqcmit was not being executed, many thanks for the pointers above which helped us find this. Code amended, retested, cause proven in the bad version and fixed in the new, job done. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Tue Nov 02, 2010 1:09 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| tisged wrote: |
| issue resolved, application error found whereby the mqcmit was not being executed, many thanks for the pointers above which helped us find this. Code amended, retested, cause proven in the bad version and fixed in the new, job done. |
Also use best practice. Never rely on a default behavior for commit/rollback. Allways ask for an explicit commit/rollback in the code. Remember that the default behavior is not the same on all platforms. 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Tue Nov 02, 2010 5:21 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9472
Location: US: west coast, almost. Otherwise, enroute.
|
Programmer deserves a swift smack with a trout.
_________________
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 |
|
|
|
|
