| Author |
Message
|
| srinivas Raju |
 Posted: Wed Feb 21, 2007 3:26 am Post subject: XMITQ full - Message lost!!! |
 |
|
Novice
Joined: 20 Feb 2007
Posts: 22
Location: India
|
Hi,
i am working with MQv6.0 on windows platform. here i have problem of message loss!
My channel is in retrying mode, my XMIT QDepth is set to 5 and my current depth is also 5 , When the 6th message was sent i could not locate it on the
transmission queue. Where can i find the 6th message ....it is not in the dead letter queue as well ...
I used the amqsput utility program ...is it so that this utility program does not have the intelligence to handle exceptions.
In a real time scenario I guess if I use a Java base class I would need to build a intelligent TRY-CATCH block or something ...Your inputs in this message loss regards at the application side would be very helpful.
thank you in advance,
Sreenu |
|
| Back to top |
|
 |
| jefflowrey |
| Posted: Wed Feb 21, 2007 3:30 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
Did you set the qremote to DEFPSIST(YES)?
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Feb 21, 2007 3:35 am Post subject: Re: XMITQ full - Message lost!!! |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| srinivas Raju wrote: |
My channel is in retrying mode, my XMIT QDepth is set to 5 and my current depth is also 5 , When the 6th message was sent i could not locate it on the
transmission queue. |
What is the maximum depth of the xmitq queue?
Did the put return any reason codes?
Are your messages persistent?
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| srinivas Raju |
| Posted: Wed Feb 21, 2007 3:48 am Post subject: XMITQ full - Message lost |
|
|
Novice
Joined: 20 Feb 2007
Posts: 22
Location: India
|
Qdepth is 5 and meaages are persistent
when i put 6th message Obsolutely it could't reside in TRX queue. Bcoz TRXQ depth is 5. But i like to konw..where can i find that message in this case |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Feb 21, 2007 3:53 am Post subject: Re: XMITQ full - Message lost |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| srinivas Raju wrote: |
| Qdepth is 5 and meaages are persistent |
So the MAXDEPTH is set artifically low on the xmitq to 5? And you're certain the message is set to be persistent rather than the default of non-persistent?
If this is the case, the message should have been delivered to the dead letter queue assigned to the queue manager. If it's not there, I'd double check the message persistence and if it really is persistent check the result of the put opperation - another possible outcome is a "queue full" reason code on put.
After that, look for log messages.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| srinivas Raju |
| Posted: Wed Feb 21, 2007 4:02 am Post subject: XMITQ full - Message lost!!! |
|
|
Novice
Joined: 20 Feb 2007
Posts: 22
Location: India
|
qremote is set to DEFPSIST(NO)
maximum depth of the xmitq queue = 5
Reason Code returned is 2053.
I understand that the application was unable to successfully complete the PUT operation ...what I am interested to know is where would this message be ...and I would like to state again that I am using the amqsput utility program.
Also it would be helpful if you could throw some light on how to handle such real-time situations where a possibility of the transmission queue becoming FULL is likely to occur.
Thanks,
Sreenu |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Wed Feb 21, 2007 4:11 am Post subject: Re: XMITQ full - Message lost!!! |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| srinivas Raju wrote: |
qremote is set to DEFPSIST(NO)
maximum depth of the xmitq queue = 5
Reason Code returned is 2053.
I understand that the application was unable to successfully complete the PUT operation ...what I am interested to know is where would this message be ...and I would like to state again that I am using the amqsput utility program.
Also it would be helpful if you could throw some light on how to handle such real-time situations where a possibility of the transmission queue becoming FULL is likely to occur.
Thanks,
Sreenu |
If the defpsist on the qr is set to no and you are using amqsput the message is not persistent.
I would still have a look at the DLQ and check if it made it there.
From your post I gather that your channel is in stopped mode.
Not checking the RC on the put exposes you to all sort of problems the least one being the loss of data...
Enjoy 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Feb 21, 2007 4:13 am Post subject: Re: XMITQ full - Message lost!!! |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| srinivas Raju wrote: |
| qremote is set to DEFPSIST(NO) |
So the messages are not persistent then..... 
| srinivas Raju wrote: |
| Reason Code returned is 2053. |
As I suspected, that's a queue full error.
| srinivas Raju wrote: |
| I understand that the application was unable to successfully complete the PUT operation ...what I am interested to know is where would this message be |
If it was not successfully PUT into MQ, it's still in your program. This is true for all MQ applications not just the sample. It's the same principle as adding a row to a database & getting an SQL code back for duplicate key or some such. The new data's not sloshing around in the database someplace....
| srinivas Raju wrote: |
Also it would be helpful if you could throw some light on how to handle such real-time situations where a possibility of the transmission queue becoming FULL is likely to occur.
|
1) Trap reason codes on MQ opperations like PUT and code applications to handle them appropriately
2) Use appropriate monitoring to detect such situations before they become critical
3) Have proper handling strategies to deal with such situations when detected
4) Use persistent messaging to prevent data loss
5) Always have a dead letter queue.
Other hints and tips may be equally valid 
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| Nigelg |
| Posted: Wed Feb 21, 2007 6:03 am Post subject: |
|
|
Grand Master
Joined: 02 Aug 2004
Posts: 1046
|
| Quote: |
| I used the amqsput utility program |
amqsput is not a utility, it is a sample.
You are right, it does not have the intelligence to handle exceptions. You have to supply the intelligence when you modify the sample to your own requirements and specification to produce a utility program you can use.
_________________
MQSeries.net helps those who help themselves.. |
|
| Back to top |
|
|
| kevinf2349 |
| Posted: Wed Feb 21, 2007 6:12 am Post subject: |
|
|
Grand Master
Joined: 28 Feb 2003
Posts: 1311
Location: USA
|
| Quote: |
Also it would be helpful if you could throw some light on how to handle such real-time situations where a possibility of the transmission queue becoming FULL is likely to occur.
|
My suggestion would be to sort out why messages aren't flowing out of the transmission queue. It could be lots of reasons, too numerous to have a standard and set response too. This is when your MQ skills come into play to find out exactly why the xmitq has filled up. It could be, triggering issues, network issues, firewall issues, application issues, operator issues, even MQ network design issues.
A MQ monitoring program should be able to send alerts whenever the xmitq was backing up. |
|
| Back to top |
|
|
| exerk |
| Posted: Wed Feb 21, 2007 7:31 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
If you are using amqsput the sample will discard any messages it cannot place on the queue and return:
MQPUT ended with reason code 2053
Which translates to:
2053 0x00000805 MQRC_Q_FULL
As far as I am concerned any application should be coded to deal with the above condition as it is up to the application to decide what to do with the content of the buffer.
_________________
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 |
|
|
| bruce2359 |
| Posted: Wed Feb 21, 2007 7:40 am Post subject: |
|
|
Guest
|
2053 tells you that the put of the 6th message failed. The sample program detected the queue full condition and passed the reason code 2053 to you, the user of the program.
Thus, there was no 6th message. There was a 6th attempt - which failed.
Last edited by bruce2359 on Wed Feb 21, 2007 7:53 am; edited 1 time in total |
|
| Back to top |
|
|
| bbburson |
| Posted: Wed Feb 21, 2007 7:47 am Post subject: |
|
|
Partisan
Joined: 06 Jan 2004
Posts: 378
Location: Nowhere near a queue manager
|
| bruce2359 wrote: |
| Thus, there was no 6th message. There was a 6th attempt - which failed. |
Well stated. |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Feb 21, 2007 7:49 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| bruce2359 wrote: |
Thus, there was no 6th message. There was a 6th attempt - which failed. |
I said that. But you said it better! 
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Wed Feb 21, 2007 8:02 am Post subject: |
|
|
Guest
|
From a college philosophy class:
Two philosophers pass on a road. Each has a sack that can hold 5 stones (MAXSTONEDEPTH of 5). Later, each looks into his own sack. One finds that his sack only has 4 stones (CURSTONEDEPTH). The other mans sack holds 5 stones.
So, what happened to the missing stone? |
|
| Back to top |
|
|
|
|
