| Author |
Message
|
| vinumon |
 Posted: Sat Mar 04, 2017 11:16 pm Post subject: Queuemanager unable to commit the transaction. |
 |
|
Acolyte
Joined: 06 May 2014
Posts: 59
|
Broker QM is posting message to a remote QM via DQM , from where application ( java) receives the messages.
Queuemanager is unable to commit the transaction, causing application to get 2033 , for subsequent messages. In application logs..its saying waiting for client to finish writing or commit.
Currently DEFPRESP(SYNC) , is set on the queue, where application is receiving message.
Do we need to change this to DEFPRESP(ASYNC), or any other values on QM or at queue level ? |
|
| Back to top |
|
 |
| smdavies99 |
| Posted: Sat Mar 04, 2017 11:36 pm Post subject: |
|
|
Jedi Council
Joined: 10 Feb 2003
Posts: 6076
Location: Somewhere over the Rainbow this side of Never-never land.
|
The QMGR does not commit anything unless it is told to. The application working with the data needs to tell the QMGR that 'I'm done with this message. go deal with it'. IF that means mmoving it to another QMGR it will do it then.
Getting a 2033 simply means 'no message available' or in your case 'no committed message available to be read'.
Applications that read messages MUST to be able to handle this.
If the reading client is doing something to determine that there is an uncomitted message on the queue then it needs to stop doing that and handle the 2033 more legantly.
It is entirely possible for the writing application to roll back the message because of some error.
That said, your situation with two queue manager is a bit odd.
How does the reading app know that there is a message (uncommitted) on the queue?
Was the message committed by the writing app?
I've never had to mess around with DEFPRESP before. Perhaps there are some scenarios where changing it is justified. Why do you think that you need to change it?
IF the writing app is taking a long time to commit the message and thus make it available for reading/consumption why do you think that changing this prarameter will fix the issue?
We really need to know a lot more detail (the devil is in the detail) in order to get to the bottom of your problem.
_________________
WMQ User since 1999
MQSI/WBI/WMB/'Thingy' User since 2002
Linux user since 1995
Every time you reinvent the wheel the more square it gets (anon). If in doubt think and investigate before you ask silly questions. |
|
| Back to top |
|
|
| vinumon |
| Posted: Sat Mar 04, 2017 11:46 pm Post subject: |
|
|
Acolyte
Joined: 06 May 2014
Posts: 59
|
The scenario is that Broker puts message to a queue with an expiry set on message as 3 sec , and these message goes to the destination QM, which is on a different server via DQM. On the destination QM, java application is connected to receive message. If the java application is not consuming message within 3 secs then it expires. In this case java Application is keep on polling for queue depth and got the queue depth as 1, then it tried to get the message, but got 2033 exception.
And also noticed that subsequent messages have not reached the remote queue and expired in the transmission queue itself.
--? Seems the first message is not committed and blocked the subsequent messages in the transmission queue.
Please advise what could be the reason for the uncommitted messages between 2 QMs in DQM. |
|
| Back to top |
|
|
| PaulClarke |
| Posted: Sun Mar 05, 2017 12:51 am Post subject: |
|
|
Grand Master
Joined: 17 Nov 2005
Posts: 1002
Location: New Zealand
|
I don't understand your statement "In this case java Application is keep on polling for queue depth and got the queue depth as 1". I hope the application is not really doing this. You don't, for example, issue MQINQ calls until you see a non-zero depth and then issue MQGET to get the message. Just because the queue depth is non-zero doesn't mean a message is available or indeed that it matches you selection criteria or that some other application isn't going to get it first. The receiving application should issue an MQGET(wait) and wait around for an appropriate amount of time for the message to arrive.
Regards,
Paul.
_________________
Paul Clarke
MQGem Software
www.mqgem.com |
|
| Back to top |
|
|
| vinumon |
| Posted: Sun Mar 05, 2017 4:32 am Post subject: |
|
|
Acolyte
Joined: 06 May 2014
Posts: 59
|
This is the error seen in the application logs
2017-02-28 21:21:01,241 ERROR [c.p.i.w.l.MQListener:checkForMessage:1193] Queue Depth 0 in Queue queue1
2017-02-28 21:21:01,245 ERROR [c.p.i.w.l.MQListener:checkForMessage:1193] Queue Depth 0 in Queue queue1
2017-02-28 21:21:01,247 ERROR [c.p.i.w.l.MQListener:checkForMessage:1193] Queue Depth 1 in Queue queue1
2017-02-28 21:21:01,250 ERROR [c.p.i.w.l.MQListener:checkForMessage:1214] Waiting for the client to finish writing or commit.
2017-02-28 21:21:01,253 ERROR [c.p.i.w.l.MQListener:checkForMessage:1214] Waiting for the client to finish writing or commit.
2017-02-28 21:21:01,257 ERROR [c.p.i.w.l.MQListener:checkForMessage:1214] Waiting for the client to finish writing or commit.
2017-02-28 21:21:01,261 ERROR [c.p.i.w.l.MQListener:checkForMessage:1214] Waiting for the client to finish writing or commit.
2017-02-28 21:21:01,262 ERROR [c.p.i.w.l.MQListener:checkForMessage:1214] Waiting for the client to finish writing or commit.
2017-02-28 21:21:01,265 ERROR [c.p.i.w.l.MQListener:checkForMessage:1214] Waiting for the client to finish writing or commit.
2017-02-28 21:21:01,267 ERROR [c.p.i.w.l.MQListener:checkForMessage:1214] Waiting for the client to finish writing or commit.
2017-02-28 21:21:01,269 ERROR [c.p.i.w.l.MQListener:checkForMessage:1214] Waiting for the client to finish writing or commit.
2017-02-28 21:21:01,272 ERROR [c.p.i.w.l.MQListener:checkForMessage:1214] Waiting for the client to finish writing or commit.
2017-02-28 21:21:01,275 ERROR [c.p.i.w.l.MQListener:checkForMessage:1214] Waiting for the client to finish writing or commit.
2017-02-28 21:21:01,277 ERROR [c.p.i.w.l.MQListener:checkForMessage:1214] Waiting for the client to finish writing or commit.
2017-02-28 21:21:01,280 ERROR [c.p.i.w.l.MQListener:checkForMessage:1214] Waiting for the client to finish writing or commit.
2017-02-28 21:21:01,281 ERROR [c.p.i.w.l.MQListener:checkForMessage:1214] Waiting for the client to finish writing or commit.
2017-02-28 21:21:01,285 ERROR [c.p.i.w.l.MQListener:checkForMessage:1214] Waiting for the client to finish writing or commit.
2017-02-28 21:21:01,288 ERROR [c.p.i.w.l.MQListener:checkForMessage:1214] Waiting for the client to finish writing or commit.
2017-02-28 21:21:01,291 ERROR [c.p.i.w.l.MQListener:checkForMessage:1214] Waiting for the client to finish writing or commit.
2017-02-28 21:21:01,293 ERROR [c.p.i.w.l.MQListener:checkForMessage:1214] Waiting for the client to finish writing or commit.
2017-02-28 21:21:01,296 ERROR [c.p.i.w.l.MQListener:checkForMessage:1214] Waiting for the client to finish writing or commit.
2017-02-28 21:21:01,300 ERROR [c.p.i.w.l.MQListener:checkForMessage:1214] Waiting for the client to finish writing or commit.
2017-02-28 21:21:01,303 ERROR [c.p.i.w.l.MQListener:checkForMessage:1214] Waiting for the client to finish writing or commit.
2017-02-28 21:21:01,306 ERROR |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Sun Mar 05, 2017 5:37 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
Those errors are not precise MQ reason codes but application specific entries.
It is a bad design for an application to inquire on the queue depth and take action on that value, as you are demonstrating. This topic has been discussed many times here, please search. Do you call your friend to see if he answers, so you can see if he is there to decide if you should hang up and call him to start the actual conversation?
If the app was corrected to issue MQGET with an appropriate wait interval, it would only pick up messages if and when they were available, and you wouldn't get hundreds of error entries in your app error log every second.
The 3 second expiry is very small. Add in the amount of time it takes to trigger the SNDR channel, add in the time it takes the RCVR channel to commit the messages in the batch, which could be a LOT more than 3 seconds based on the batch settings of the channel.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| gbaddeley |
| Posted: Sun Mar 05, 2017 3:20 pm Post subject: Re: Queuemanager unable to commit the transaction. |
|
|
Jedi Knight
Joined: 25 Mar 2003
Posts: 2538
Location: Melbourne, Australia
|
| vinumon wrote: |
| Broker QM is posting message to a remote QM via DQM , from where application ( java) receives the messages. |
There are up to 3 Units Of Work involved in DQM messaging.
1) Producer app puts msg to QREMOTE (resolves to XMITQ) and then commits.
2) DQM channel agents on source and destination qmgrs do a UOW get on xmitq and put on destination queue.
3) Consumer app gets msg from QLOCAL in UOW.
3 seconds seems like a short expiry. Do you really want MQ to throw away messages if they have not been consumed in that time? They can't be very important....
_________________
Glenn |
|
| Back to top |
|
|
| vinumon |
| Posted: Sun Mar 05, 2017 10:13 pm Post subject: |
|
|
Acolyte
Joined: 06 May 2014
Posts: 59
|
This issue occurs intermittently only, also can we suspect that the error
"Waiting for the client to finish writing or commit. "
is because that the queue manager is taking time to commit the transaction and subsequently blocking the next requests unless the transaction is completed ? |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Sun Mar 05, 2017 11:27 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
Two-phase commit protocol does take some time to complete. It takes as long as it takes there are multiple network flows between the resource managers it is not the qmgrtaking too long
_________________
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 |
|
|
| vinumon |
| Posted: Mon Mar 06, 2017 1:26 am Post subject: |
|
|
Acolyte
Joined: 06 May 2014
Posts: 59
|
As mentioned earlier, here message is first initiated from broker and in the broker MQOUTPUT node the transaction mode property is set to NO. ie asych call, where as the target queue where java application consumes the DEFPRESP is synch.
If we change this to asynch , will the issue gets solved? |
|
| Back to top |
|
|
| Vitor |
| Posted: Mon Mar 06, 2017 5:34 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| vinumon wrote: |
| If we change this to asynch , will the issue gets solved? |
No.
If you fix your design, this issue will get solved.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
|
|
