| Author |
Message
|
| PeterPotkay |
 Posted: Fri Aug 02, 2002 10:34 am Post subject: Truncated Messages and the Backout Count |
 |
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
About to test some code on the mainframe and before I crash the TCODE because of an endless loop, I need your guys opinion.
Mainframe app is triggered OnFirst. Does GETs with No-Syncpoint, Does not Accept truncated messages, specifies a buffer of 500 bytes.
If a message is put on the queue that is 501 bytes, the app will be triggered, but the GET will fail with reason MQRC_TRUNCATED_MSG_FAILED.
The manual says that the message will not be removed.
The app will do its error process and then end. The queue will be closed. If the message was not removed, and a triggered on first queue is being closed with a queue depth of greater than 0, a new trigger message will be generated. Poisened message loop for an app that gets outside of syncpoint!
Normally no problem. Code some logic that checks the MQMD-Backoutcount immediatly after the GET and handle values greater than n. But if the message was never removed from the queue, will the backout count be increased every time the GET fails because of a truncated message error?
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
 |
| bduncan |
| Posted: Fri Aug 02, 2002 11:53 am Post subject: |
|
|
Padawan
Joined: 11 Apr 2001
Posts: 1554
Location: Silicon Valley
|
I don't believe so. As far as I know, the backout count can only be increased as the result of an MQBACK, either explicitly by the application, or implicitly by the queue manager if the application dies, queue manager dies, etc...
So since you aren't even using syncpoint (and even if you were, you aren't actually removing the message from the queue) the backout count shouldn't increase.
_________________
Brandon Duncan
IBM Certified MQSeries Specialist
MQSeries.net forum moderator |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Fri Aug 02, 2002 7:19 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
So I'll endless loop with no way of knowing it via the code?
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| bduncan |
| Posted: Sat Aug 03, 2002 8:02 am Post subject: |
|
|
Padawan
Joined: 11 Apr 2001
Posts: 1554
Location: Silicon Valley
|
Well, to tell you the truth Peter, I don't think the trigger is going to refire. If you have the queue set to trigger type first, I believe it will only fire the trigger message if the depth of the queue increases from 0 to 1. Since the MQGET never actually removes the message from the queue, the depth never goes from 0 to 1 again, so you shouldn't get additional trigger messages. Now I could be wrong on that, but from my experience, I would typically run in to the scenario where I had a triggered queue (type first) and at some point my application would die, and I would end up filling the queue up because the trigger would never fire again. The only time I got an infinite loop was in a situation where I would have a trigger application that tried to do a SQL query based on the content of the message. The query would fail, I would rollback the message, my application would be immediately retriggered, and because I wasn't checking the backout count I would basically loop forever on this poison message. However I don't think this is what is going to happen in your case since I'm not convinced the message is actually removed (causing the queue depth to go from 1 back to 0).
_________________
Brandon Duncan
IBM Certified MQSeries Specialist
MQSeries.net forum moderator |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Sat Aug 03, 2002 2:08 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
I guess I'm gonn have to bite the bullet here and just try it on Monday. I'll put in some temp code to automatically end the app in case it does loop, which I am leaning to thinking it will.
Technically, when you rollback a message you aren't putting it back to the queue. I don't think it ever left. Doesn't the original copy of the message stay on the queue if gotten under syncpoint (of course it is unavailable to anyone else)? Only when a commit is issued does the QM assume its safe to remove the message, no? If so, in your situation, the retrigger was not being caused by the message being "reput" to the queue, but rather you were satisfying Trigger Condition # 12, (just like I will be in this test), that is, closing a Trig First queue when its depth is greater than zero.
Put another way, since the get never completly 100% finishes in our cases, its like the following psuedo code is executing, which would cause an infinite triggering condition
1.)Message is PUT, Q depth goes from 0 to 1.
2.)QM generates trigger message to init queue.
3.)Trig Monitor sees trigger message, sees app is not running, and starts app.
4.)MQCONN
MQOPEN
MQCLOSE (QM generates another trigger message to the init queue cause Condition 12 just got satisfied)
MQDISC
5.)App ends Go to step 3.
Well, maybe the backoutcount will be incremented. In your case it does (GET works and then is rolled back) and the message never TECHNICALLY left the queue, so maybe in my case with the GET failing and the message never leaving the queue, the QM will be smart enuff to bump up the count. Interesting.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| kirani |
| Posted: Sun Aug 04, 2002 6:50 pm Post subject: |
|
|
Jedi Knight
Joined: 05 Sep 2001
Posts: 3779
Location: Torrance, CA, USA
|
Peter,
I don't think the BackoutCount will be incremented in your case.
Since you are not specifying MQGMO_ACCEPT_TRUNCATED_MSG in MQGet Option, your message will not be removed from the queue at all. You will get warning message, Completion Code 1, Reason Code: 2080 MQRC_TRUNCATED_MSG_FAILED.
As Brandon said, trigger message will be generated only when your queue depth goes from 0 to 1. Typically, you should use trigger type FIRST for starting a program, which will continue until there are no more messages to process on the queue.
Let us know what you find in your testing.
_________________
Kiran
IBM Cert. Solution Designer & System Administrator - WBIMB V5
IBM Cert. Solutions Expert - WMQI
IBM Cert. Specialist - WMQI, MQSeries
IBM Cert. Developer - MQSeries
|
|
| Back to top |
|
|
| nimconsult |
| Posted: Sun Aug 04, 2002 10:33 pm Post subject: |
|
|
Master
Joined: 22 May 2002
Posts: 268
Location: NIMCONSULT - Belgium
|
Hi Peter,
I don't think the backout count will be increased neither.
As you mentionned I think that MQ will re-trigger your app, because trigger first does not only trigger when going from 0 to 1 as assumed in other posts.
One of the other situations where MQ generates a trigger is that the last application that closes the queue leaves messages in the queue. The reason why MQ Series does that is that there is a time window between your last MQGET and MQCLOSE where one or more messages could reach the queue. So even the best written application can miss messages because of this small window.
Let the forum be informed of your test results!
Regards,
_________________
Nicolas Maréchal
Senior Architect - Partner
NIMCONSULT Software Architecture Services (Belgium)
http://www.nimconsult.be |
|
| Back to top |
|
|
| bob_buxton |
| Posted: Mon Aug 05, 2002 12:06 am Post subject: |
|
|
Master
Joined: 23 Aug 2001
Posts: 266
Location: England
|
Many applications handle truncated message by allocating a larger buffer and then retrying the get. They don't expect the BO count to have been increased.
Bob
_________________
Bob Buxton
Ex-Websphere MQ Development |
|
| Back to top |
|
|
| mrlinux |
| Posted: Mon Aug 05, 2002 4:55 am Post subject: |
|
|
Grand Master
Joined: 14 Feb 2002
Posts: 1261
Location: Detroit,MI USA
|
If the 500 bytes is critical then set the MAXMSGL of the queue to 500 bytes, that way anything over 500 bytes goes to the DEAD Queue
_________________
Jeff
IBM Certified Developer MQSeries
IBM Certified Specialist MQSeries
IBM Certified Solutions Expert MQSeries |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Mon Aug 05, 2002 5:51 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
The backout count does not get incremented.
The app does get retriggered over and over.
Since this is COBOL, its not a simple matter to recall the get with a bigger buffer. I have to define the buffer in Working Storage to something like W01-Buffer PIC X(500). I don't see how I could dynamically allocate a variable buffer length. I suppose I could make a super buffer (W01-SUPER-BUFFER PIC X(1000000), and throw any thing in there if I get the truncated message error, and then throw it to an exception queue.
The other option is to code Accept_Trunacted_Message, and again put it to an exception queue, realizing I have lost any data after byte 500 (Hey, its the other side's fault for sending me to big a mesage).
I like the idea of setting the MAX message Lenght parameter the best, maybe even setting it on the remote queues as well, so the putting app immediatly knows they are screwing up.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Mon Aug 05, 2002 6:27 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
Whoops, spoke to soon about the remote defs. Max Message length is not an available parameter on a remote queue definition. That kinda stinks....
I wonder what the logic is behind not having this value available on remote queues?
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| mrlinux |
| Posted: Mon Aug 05, 2002 7:06 am Post subject: |
|
|
Grand Master
Joined: 14 Feb 2002
Posts: 1261
Location: Detroit,MI USA
|
Well if you setup a special channels for these messages you could
set the xmitq maxmsgl and that should give an error back.
_________________
Jeff
IBM Certified Developer MQSeries
IBM Certified Specialist MQSeries
IBM Certified Solutions Expert MQSeries |
|
| Back to top |
|
|
| bduncan |
| Posted: Mon Aug 05, 2002 11:19 am Post subject: |
|
|
Padawan
Joined: 11 Apr 2001
Posts: 1554
Location: Silicon Valley
|
Nicolas,
I didn't assume that the trigger would only occur when the depth goes from 0 to 1 (though that is what it sounds like from my sentence). I agree that the queue manager will retrigger if the last triggered application closes the queue while messages are still on it, but doesn't this only happen after the trigger interval has expired?
_________________
Brandon Duncan
IBM Certified MQSeries Specialist
MQSeries.net forum moderator |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Mon Aug 05, 2002 11:24 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
No it will happen immediatly after the close.
The trigger interval is used for cases where somehow we find ourselves with a closed queue and more than 0 messages on it. In this case, we will never get a trigger, UNLESS the trig interval passes. If you set it to say 5 minutes, you force the QM to say to itself every 5 minutes "OK, Its been 5 minutes since I last checked, and should another message land on this queue, even though the depth is not going from 0 to 1, treat it like it is, and generate a trigger message"
Note: Its the passage of the trigger interval time AND the arrival of one more message that cause this action.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| bduncan |
| Posted: Mon Aug 05, 2002 12:47 pm Post subject: |
|
|
Padawan
Joined: 11 Apr 2001
Posts: 1554
Location: Silicon Valley
|
Peter,
If it is as you are describing, then doesn't that make the trigger interval redundant? At what point would we ever have an amount of time elapse on a closed triggered queue with more than 0 messages, if the act of closing it in the first place immediately fires another trigger?
_________________
Brandon Duncan
IBM Certified MQSeries Specialist
MQSeries.net forum moderator |
|
| Back to top |
|
|
|
|
