| Author |
Message
|
| jefflowrey |
 Posted: Wed Feb 21, 2007 8:09 am Post subject: |
 |
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
This is what I get for bringing up Gutei.
There is no spoon.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
 |
| Vitor |
| Posted: Wed Feb 21, 2007 8:12 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| jefflowrey wrote: |
| There is no spoon. |
And Agent Smith is a security exit.... 
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| kevinf2349 |
| Posted: Wed Feb 21, 2007 8:16 am Post subject: |
|
|
Grand Master
Joined: 28 Feb 2003
Posts: 1311
Location: USA
|
Straying off topic here somewhat but this reminds me of something I was told way too many years ago........
If it is there and you can see it, it is real
If it is there and you can't see it, it is invisible
If it isn't there and you can see it, it is virtual
If it isn't there and you can't see it, it is gone! |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Wed Feb 21, 2007 8:45 am Post subject: |
|
|
Guest
|
| jefflowrey wrote: |
This is what I get for bringing up Gutei.
There is no spoon. |
So, the eternal question remains: which finger did Gutei raise? |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Wed Feb 21, 2007 8:48 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
| bruce2359 wrote: |
| jefflowrey wrote: |
This is what I get for bringing up Gutei.
There is no spoon. |
So, the eternal question remains: which finger did Gutei raise? |
Alas, Gutei proved that there also is no finger.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| tleichen |
| Posted: Wed Feb 21, 2007 11:03 am Post subject: |
|
|
Yatiri
Joined: 11 Apr 2005
Posts: 663
Location: Center of the USA
|
| bruce2359 wrote: |
| So, the eternal question remains: which finger did Gutei raise? |
I know which one I would raise... 
_________________
IBM Certified MQSeries Specialist
IBM Certified MQSeries Developer |
|
| Back to top |
|
|
| mvarghese |
| Posted: Wed Feb 21, 2007 4:03 pm Post subject: |
|
|
Centurion
Joined: 27 Sep 2006
Posts: 141
|
Hi Raju,
If you keep all the necessary objects<queues> with persitance but the application putting the message to Q as NON peristant, then it will override the Queue property.
Check do you have any Dead Q pointed to your QMGR?.
_________________
Jain Varghese |
|
| Back to top |
|
|
| kevinf2349 |
| Posted: Wed Feb 21, 2007 4:57 pm Post subject: |
|
|
Grand Master
Joined: 28 Feb 2003
Posts: 1311
Location: USA
|
| mvarghese wrote: |
Hi Raju,
If you keep all the necessary objects<queues> with persitance but the application putting the message to Q as NON peristant, then it will override the Queue property.
Check do you have any Dead Q pointed to your QMGR?. |
With all due respect the initial 'problem' has really got nothing to do with persistence. It is everything to do with what Bruce2359 said....
| Quote: |
bruce2359 wrote:
Thus, there was no 6th message. There was a 6th attempt - which failed.
|
The 6th message was never there, the PUT failed with a 2053 (Q-Full). This will happen regardless of persistency. If the sixth message was never successfully placed onto the queue it was never there to be 'lost'.
The application is what needs changing  |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Wed Feb 21, 2007 5:13 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20773
Location: LI,NY
|
| bruce2359 wrote: |
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? |
Which missing stone?? you never said that all sacks were full (maxstonedepth=curstonedepth)...
So in the beginning, in an ideal world in which we had 9 stones that were spread equally, 2 travellers had each a sack. Each sack had a maximum capacity of 5 stones.
How do you get the sacred stones to the shrine? 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| mvarghese |
| Posted: Wed Feb 21, 2007 8:27 pm Post subject: |
|
|
Centurion
Joined: 27 Sep 2006
Posts: 141
|
It will be great , put right answer to the Question, so that Newly joined person will get some Confidence in this site.Right:)
_________________
Jain Varghese |
|
| Back to top |
|
|
| srinivas Raju |
| Posted: Wed Feb 21, 2007 9:56 pm Post subject: XMITQ full - Message lost!!! |
|
|
Novice
Joined: 20 Feb 2007
Posts: 22
Location: India
|
hii bruce
Thus, there was no 6th message. There was a 6th attempt - which failed.
i agree with you..that it's made 6th attempt, but fails becoz of XMITQ full
This is possible case could happen in our application.
In this case is there any way to route the 6th message to another queues like application queus or dead letter queues if this situation occurs.
thanks
sreenu |
|
| Back to top |
|
|
| Vitor |
| Posted: Thu Feb 22, 2007 12:51 am Post subject: Re: XMITQ full - Message lost!!! |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| srinivas Raju wrote: |
In this case is there any way to route the 6th message to another queues like application queus or dead letter queues if this situation occurs.
|
Only via application logic. As was pointed out above (before it all went interesting but bizzare ) the 6th message never made it out of the application. Hence no MQ function or feature can handle it because it's not there.
We've made the point about the importance of handling reason codes returned by MQ - this is what we were getting at. Your application must look at the code, decide if it's a permanent error or not and act appropriately. For instance, if a client application gets a 2009, it should just sigh, reestablish the connection and continue. If it gets a 2035 it should bomb out because the security's fouled up somehow & if it gets a 2033 it should end gracefully because it's done.
All these are examples and should be viewed in the light of your situation, but a "queue full" is not fatal. It could just be the network's running slow (in the case you use) so you might want to consider sleeping for 10 seconds and having another go. Another possibility is to put the message to another application queue as you suggest, but I wonder at the utility this gives you. The xmitq fills, so messages start going to this alternative queue. Which then either fills up or needs to be emptied by another process. But only once the xmitq is empty or they've nowhere else to go. So the better (IMHO) option is to fix the real problem, i.e. why is the xmitq full, rather than hide messages in 1 or more other queues. (As you don't know how long the xmitq will be full, you can't be certain this other queue won't fill as well.......)
I would however urge you not to use the dead letter queue for these messages. That has a specific use within MQ and application messages on there will cause you a world of hurt. There have been some postings about this in the past you might want to look up, but in short only MQ should put messages to the DLQ.
If you decide you absolutely must use the DLQ, be certain you add the proper dead letter header first. I again entreat you not to do it.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Thu Feb 22, 2007 6:46 am Post subject: |
|
|
Guest
|
As Vitor said, this is an application design issue for you, not an mq issue.
Any queue can fill up. Application design must include 'what if' for a variety of scenarios.
Your application architects need to tell you what is the maximum number of messages that will be MQPUT - one a second, one a minute, 1000 a second, 1,000,000 hour... What is the size of the messages? With these numbers in mind, you can set max queue depth and max msg length.
But a queue can still fill up if the MQGETting program fails to start, or can't process the messages quickly enough, or as in your case, the network connection goes dead. Application must check reason codes returned from MQ and take appropriate action.
Please read the MQ Application Programmers Referene and MQ Application Programmers Guide. |
|
| Back to top |
|
|
|
|
