| Author |
Message
|
| guest468 |
 Posted: Wed Dec 06, 2006 1:00 pm Post subject: MQ Message retrieval |
 |
|
Centurion
Joined: 30 May 2006
Posts: 146
Location: NY
|
Hi
I have a question on MQ get.
what I understand is when an application connects a QM and invokes a MQGET the message will not removed immediately from the queue but only after the application commits. Is this applicale irrespective of persistence or under transactional control(MQBEGIN or not)?
And QM detects that application is down when it sees that connection is broken; is this correct? And what happens if an application never issues commit or disconnects , is there any timeout period till which QM waits and after that it rollsback the message back to the queue?
Actually we are seeing a problem in our environment. The application connects to the QM, gets the message and when we deliberately bring the application down the message is not rolledback to the queue(we checked the queue). But interestingly the application somehow gets the message back when it comes up. What would have happened in this scenario?
Thanks |
|
| Back to top |
|
 |
| killer |
| Posted: Wed Dec 06, 2006 1:18 pm Post subject: |
|
|
Apprentice
Joined: 06 Jul 2006
Posts: 35
|
| Quote: |
| [he application connects to the QM, gets the message] |
As per ur comment, the application is already receiving the message.
So it already got the message.
Following are the steps in a simple senario:-
1)Aplication make connection with QM
2)Access the Q to get the message.
3)application disconnect .
If application performed step 1 and failed in step 2,
then message is not yet received.
If application perfomed step2 and failed after step 3,
then it has got the message and after that it failed.
Last edited by killer on Wed Dec 06, 2006 1:25 pm; edited 1 time in total |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Wed Dec 06, 2006 1:21 pm Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
An MQ program has to be specifically coded to use any form of transactional control over messages.
If it is not specifically coded to do so, then the MQGET is automatically destructive, and the message is immediately removed entirely from the queue.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| guest468 |
| Posted: Wed Dec 06, 2006 1:28 pm Post subject: |
|
|
Centurion
Joined: 30 May 2006
Posts: 146
Location: NY
|
Thanks Jeff,
The application is reteiving the message under transactional control (MQBEGIN). And during the processing we brought down the application deliberately. Now MQ should have rolledback the message back to the input queue but we did not see the message there. The application completely h/w based and the concerned vendors are saying there isn't any cache or any kind of storage. Still when we brought the application up the it actually retrieved the message and sent an output message to o/p queue. What would have happened? |
|
| Back to top |
|
|
| wschutz |
| Posted: Wed Dec 06, 2006 1:55 pm Post subject: |
|
|
Jedi Knight
Joined: 02 Jun 2005
Posts: 3316
Location: IBM (retired)
|
When you say that you "didn't see the message" after the application was killed ... does that mean you didn't see curdepth go back up, or that you couldn't browse the message, or did you try retrieving the message via something like amqsget?
In any case, Jeff's point was that you also need to use MQGMO_SYNCPOINT on the MQget calls, otherwise the MQGET is outside of the UOW started by MQBEGIN.
_________________
-wayne |
|
| Back to top |
|
|
| guest468 |
| Posted: Wed Dec 06, 2006 1:58 pm Post subject: |
|
|
Centurion
Joined: 30 May 2006
Posts: 146
Location: NY
|
|
| Back to top |
|
|
| wschutz |
| Posted: Wed Dec 06, 2006 2:00 pm Post subject: |
|
|
Jedi Knight
Joined: 02 Jun 2005
Posts: 3316
Location: IBM (retired)
|
| guest468 wrote: |
| Wayne, we used amqsget. |
and the application uses MQGMO_SYNCPOINT? Can you confirm that??
_________________
-wayne |
|
| Back to top |
|
|
| guest468 |
| Posted: Wed Dec 06, 2006 2:13 pm Post subject: |
|
|
Centurion
Joined: 30 May 2006
Posts: 146
Location: NY
|
yep that's what the vendor is saying. (the application is purely hardware based).
NOTE: Actually I thought the message will be put under sync if we specify MQBEGIN. Also does the persistence play any role in sync? |
|
| Back to top |
|
|
| wschutz |
| Posted: Wed Dec 06, 2006 2:24 pm Post subject: |
|
|
Jedi Knight
Joined: 02 Jun 2005
Posts: 3316
Location: IBM (retired)
|
| guest468 wrote: |
| yep that's what the vendor is saying. (the application is purely hardware based). |
Huh?
| guest468 wrote: |
NOTE: Actually I thought the message will be put under sync if we specify MQBEGIN. Also does the persistence play any role in sync? |
No, you must specify MQxMO_SYNCPOINT (x=G or P)... it has nothing at all to do with persistence. If you don't specify syncpoint, then the messages are in a different "single" unit of work.
_________________
-wayne |
|
| Back to top |
|
|
| guest468 |
| Posted: Thu Dec 07, 2006 11:03 am Post subject: |
|
|
Centurion
Joined: 30 May 2006
Posts: 146
Location: NY
|
| Out of curiosity, what happens if an application tries to get a message under sync and waits forever. In this case, the message is locked forever. Does QMGR tries to resolve this? I mean does it wait for some time and then rollsback the message? |
|
| Back to top |
|
|
| mvic |
| Posted: Fri Dec 08, 2006 8:20 am Post subject: |
|
|
Jedi
Joined: 09 Mar 2004
Posts: 2080
|
| guest468 wrote: |
| Out of curiosity, what happens if an application tries to get a message under sync and waits forever. In this case, the message is locked forever. Does QMGR tries to resolve this? I mean does it wait for some time and then rollsback the message? |
It's difficult to understand the question here. Could you post a code sample please, and it will be possible to comment. |
|
| Back to top |
|
|
| bower5932 |
| Posted: Fri Dec 08, 2006 11:51 am Post subject: |
|
|
Jedi Knight
Joined: 27 Aug 2001
Posts: 3023
Location: Dallas, TX, USA
|
| I think he is talking about a 'long running transaction', and I agree this whole thread is a little confusing.... |
|
| Back to top |
|
|
| guest468 |
| Posted: Mon Dec 11, 2006 11:13 am Post subject: |
|
|
Centurion
Joined: 30 May 2006
Posts: 146
Location: NY
|
Sorry about the confusion. Actually I am trying to understand the QMGR's role in resolving a long running transaction. Let's say an application starts the message get operation under sync and for some reason it hangs but the connection is kept alive (ex: application is waiting indefinitely for something else before commit). In this scenario the message is stuck forever. Does the QMGR tries to resolve this situation?
Thanks. |
|
| Back to top |
|
|
| mvic |
| Posted: Mon Dec 11, 2006 12:45 pm Post subject: |
|
|
Jedi
Joined: 09 Mar 2004
Posts: 2080
|
| guest468 wrote: |
Does the QMGR tries to resolve this situation?
Thanks. |
No, if the administrator believes an app is holding open a very long transaction, then the best option is to end the app. Then, supposing the app did not call MQDISC, the queue manager will roll back the long running transaction within 10 seconds. |
|
| Back to top |
|
|
|
|
