| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
| AMQ8143: WebSphere MQ queue not empty while xmit Q clear |
« View previous topic :: View next topic » |
| Author |
Message
|
| HubertKleinmanns |
 Posted: Wed May 13, 2009 2:50 am Post subject: |
 |
|
Shaman
Joined: 24 Feb 2004
Posts: 732
Location: Germany
|
| exerk wrote: |
| sumit wrote: |
| ...I can understand about losing messages. But how can they be duplicated? |
Because if you resolve by rolling back, a message will be 're-sent'. The in-doubt is because the queue manager cannot be certain the other end has received and committed, and if the other end then receives that message 'again' it will in effect be a duplicate.. |
Or more exactly:
RESOLVE CHL(...) ACTION(COMMIT): Channel assumes, that the last message batch has been received - and removes the uncommited messages from the XmitQ. When the receiving end did not really get the messages, these are lost.
RESOLVE CHL(...) ACTION(BACKOUT): Channel assumes, that the last message batch has NOT been received - and sends the uncommited messages again. When the receiving end got already the messages, these are duplicated.
_________________
Regards
Hubert |
|
| Back to top |
|
 |
| exerk |
| Posted: Wed May 13, 2009 3:09 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| HubertKleinmanns wrote: |
Or more exactly:
RESOLVE CHL(...) ACTION(COMMIT): Channel assumes, that the last message batch has been received - and removes the uncommited messages from the XmitQ. When the receiving end did not really get the messages, these are lost.
RESOLVE CHL(...) ACTION(BACKOUT): Channel assumes, that the last message batch has NOT been received - and sends the uncommited messages again. When the receiving end got already the messages, these are duplicated. |
Most eruditely put, thank you...
_________________
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 |
|
|
| sumit |
| Posted: Wed May 13, 2009 6:22 am Post subject: |
|
|
Partisan
Joined: 19 Jan 2006
Posts: 398
|
OK, that means 'under certain circumstances' MQ doesn't follow 'once and certain' delivery of messages.
I was thinking that the confirmation of message delivery in target queue comes in split seconds. And UNCOM(YES) means that the message is somewhere in the transmission media and 'something' happended to the network, etc. but not in the destination queue else it should be committed.
_________________
Regards
Sumit |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed May 13, 2009 6:25 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| sumit wrote: |
| OK, that means 'under certain circumstances' MQ doesn't follow 'once and certain' delivery of messages. |
No, it means that under certain circumstances WMQ needs assistance to honour the once and once only (rather than certain, which WMQ does not provide) delivery of messages.
If it wasn't interested in following the once and once only, the MCAs would flip a coin and either commit or backout themselves, without asking for manual resolution.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| sumit |
| Posted: Wed May 13, 2009 6:40 am Post subject: |
|
|
Partisan
Joined: 19 Jan 2006
Posts: 398
|
So, it means.. it's always wise to check at end site whether they receive the message or not before doing backout.
Or may be, ask them to discard the duplicate message when they receive it.
_________________
Regards
Sumit |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed May 13, 2009 6:51 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| sumit wrote: |
So, it means.. it's always wise to check at end site whether they receive the message or not before doing backout.
Or may be, ask them to discard the duplicate message when they receive it. |
Exactly so.
If the MCAs can work out what to do, they will and this situation will not arise. If the channel is in doubt, then (unsurprisingly) it's uncertain what the correct action is. So the choice is passed to the administrator, who must use the additional information available to a human (including use of phone or email) to decide on a course of action.
Bottom line - this is an error condition. It needs to be investigated.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Wed May 13, 2009 6:51 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9475
Location: US: west coast, almost. Otherwise, enroute.
|
| Quote: |
| So, it means.. it's always wise to check at end site whether they receive the message or not before doing backout. Or may be, ask them to discard the duplicate message when they receive it. |
I would have said that it a nice thing to do.
I seriously doubt (from experience) that the end site sysadmins or app developers will be able to easily, and in any reasonable time-frame, determine if the messages have/have not arrived, and where they arrived.
A well-behaved application will be able to deal with duplicate or missing messages and replies. If the app in question is well-behaved, then it makes no difference whether you commit or backout.
_________________
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 |
|
|
| Vitor |
| Posted: Wed May 13, 2009 6:57 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| bruce2359 wrote: |
| I would have said that it a nice thing to do. |
I disagree - it's wise. Even if they can't tell in a reasonable time-frame, you can agree what's the best course of action with them. For instance if the application / business would sooner risk duplicates than loss, this leads you to backout. If instead they feel more confident of application auditing to identify and retry lost, this leads to commit.
It all hinges on design, architecture and business attitude. Often in a context wider than the app receiving the message.
| bruce2359 wrote: |
| A well-behaved application will be able to deal with duplicate or missing messages and replies. If the app in question is well-behaved, then it makes no difference whether you commit or backout. |
There I do agree. But experience teaches that you more often end up identifying which way is least likely to make the application (or system) fail.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| George Carey |
| Posted: Wed May 13, 2009 7:41 am Post subject: smart app!! |
|
|
Knight
Joined: 29 Jan 2007
Posts: 500
Location: DC
|
bruce2359 said:
| Quote: |
| ...If the app in question is well-behaved, then it makes no difference whether you commit or backout. ... |
This would have to be a very well behaved and smart app indeed, omnicient even! No need for assured or once and only once delivery with an app like that, it knows what it needs, when it needs it , when it got it and when it didn't get it !!!
Those are the kinda apps I like.
Rgrds
P.S. I guess this 2007 post has been brought up to date 
_________________
"Truth is ... grasping the virtually unconditioned",
Bernard F. Lonergan S.J.
(from book titled "Insight" subtitled "A Study of Human Understanding") |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Wed May 13, 2009 8:11 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9475
Location: US: west coast, almost. Otherwise, enroute.
|
| Quote: |
| This would have to be a very well behaved and smart app indeed, omnicient even! No need for assured or once and only once delivery with an app like that, it knows what it needs, when it needs it , when it got it and when it didn't get it !!! |
Not omniscient, just aware. Once and once-only, with no loss or duplication, is MQs job, but with no sensitivity to message content. If an errant program sent the same exact request message twice, you couldn't very well blame MQ for the duplication, could you?
Well-behaved is not an MQ term. It applies to applications with or without MQ as the transport.
Briefly: A well-behaved requesting application would know that it sent request (message) 1 (of some important content), and received (or failed to receive) reply message 1. It would re-submit request 1 if it failed to receive the expected reply.
The replying application would know that it received request 1, and sent reply 1. It would, if well-behaved, know that it had already received and replied to request 1. It would deny/reject a duplicate. It would also know that if the next inbound request was 3, that it had not received request 2, and it would notify the requesting application of that fact.
Best-practice demands well-behaved applications; but there aren't all that many out there. We live with what we have.
_________________
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: Wed May 13, 2009 8:19 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| bruce2359 wrote: |
Briefly: A well-behaved requesting application would know that it sent request (message) 1 (of some important content), and received (or failed to receive) reply message 1. It would re-submit request 1 if it failed to receive the expected reply.
The replying application would know that it received request 1, and sent reply 1. It would, if well-behaved, know that it had already received and replied to request 1. It would deny/reject a duplicate. It would also know that if the next inbound request was 3, that it had not received request 2, and it would notify the requesting application of that fact.
|
Don't look now, but I think you just described a SNDR/RCVR pair of MCAs! 
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Wed May 13, 2009 8:22 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| bruce2359 wrote: |
| Quote: |
| So, it means.. it's always wise to check at end site whether they receive the message or not before doing backout. Or may be, ask them to discard the duplicate message when they receive it. |
I would have said that it a nice thing to do.
I seriously doubt (from experience) that the end site sysadmins or app developers will be able to easily, and in any reasonable time-frame, determine if the messages have/have not arrived, and where they arrived.
|
All they have to do is look at the LUWID.
http://publib.boulder.ibm.com/infocenter/wmqv6/v6r0/topic/com.ibm.mq.csqzae.doc/ic11350_.htm
| Quote: |
If the two LUWIDs are the same, the receiving side has committed the unit of work that the sender considers to be in doubt. The sending side can now remove the in-doubt messages from the transmission queue and re-enable it. This is done with the following channel RESOLVE command:
RESOLVE CHANNEL(name) ACTION(COMMIT)
If the two LUWIDs are different, the receiving side has not committed the unit of work that the sender considers to be in doubt. The sending side needs to retain the in-doubt messages on the transmission queue and re-send them. This is done with the following channel RESOLVE command:
RESOLVE CHANNEL(name) ACTION(BACKOUT)
|
This is pretty straightforward.....makes me think, Why can't the channels do this themselves and automatically? 
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| George Carey |
| Posted: Wed May 13, 2009 8:37 am Post subject: |
|
|
Knight
Joined: 29 Jan 2007
Posts: 500
Location: DC
|
bruce2359:
| Quote: |
| "... Once and once-only, with no loss or duplication ..." |
Not sure if you were intending to be redundant but these two attributes are redundant ... assured delivery is the other attribute which encompasses the transactional aspect of the message delivery.
But the indoubt case is the one we are talking about and for all non- "Well Behaved" applications an out of band decision will likely need to be made on whether a message was delivered once and only once. The assured delivery says we still have the message available to make that decision.
I do however give my vote for all applications to be well behaved. Which is I think some what like Miss America contestant saying she is for World Peace. 
_________________
"Truth is ... grasping the virtually unconditioned",
Bernard F. Lonergan S.J.
(from book titled "Insight" subtitled "A Study of Human Understanding") |
|
| Back to top |
|
|
| George Carey |
| Posted: Wed May 13, 2009 8:44 am Post subject: |
|
|
Knight
Joined: 29 Jan 2007
Posts: 500
Location: DC
|
PeterP:
"
| Quote: |
| ...This is pretty straightforward.....makes me think, Why can't the channels do this themselves and automatically?.." |
My thought exactly,You beat me to your own question .... Why indeed !!
_________________
"Truth is ... grasping the virtually unconditioned",
Bernard F. Lonergan S.J.
(from book titled "Insight" subtitled "A Study of Human Understanding") |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Wed May 13, 2009 9:08 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9475
Location: US: west coast, almost. Otherwise, enroute.
|
Redundant, repetitive, whatever. Let's keep the discussion to the discussion.
| Quote: |
| All they have to do is look at the LUWID. |
Yes, if both channel end MCAs believe that they are intact. Prior posts have brought up some situations where INDOUBT is beyond the MCAs to resolve on their own.
The receiving end folks delete and redefine the channel end. The sender has a good LUWID and SEQWRAP, but the receiver does not.
_________________
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 |
|
|
|
|
|
|
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
|
|
|
|
