| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
| How to find and open a mq.ini file? |
« View previous topic :: View next topic » |
| Author |
Message
|
| bruce2359 |
 Posted: Fri Feb 05, 2010 12:55 pm Post subject: |
 |
|
Poobah
Joined: 05 Jan 2008
Posts: 9396
Location: US: west coast, almost. Otherwise, enroute.
|
| Quote: |
| ...either because the Expiry set on them has not elapsed or because NO EXPIRY was set. |
Did you mean EXPIRY_UNLIMITED (-1) - the initial value of the expiry field?
Since the expiry field is MQLONG, I'd suspect that NO EXPIRY would be nulls or something that would/might cause the put to fail - although I haven't tested this.
_________________
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 |
|
 |
| mqjeff |
| Posted: Fri Feb 05, 2010 1:03 pm Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| bruce2359 wrote: |
| Quote: |
| ...either because the Expiry set on them has not elapsed or because NO EXPIRY was set. |
Did you mean EXPIRY_UNLIMITED (-1) - the initial value of the expiry field? |
I'm sure I have a rubber mallet here somewhere. Ah, 
I did not say "was set to NO EXPIRY". I said "NO EXPIRY was set". It is hard to believe that was not clear as "no action was taken to set a specific Expiry value", and even less clear how it could possible be interpreted as "action was taken to set a specific NULL value".
If you want to argue about what "no action was taken to set a specific Expiry value" produces as the Expiry on a given message, then you are welcome to argue. I, however, will not be participating. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Fri Feb 05, 2010 1:14 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9396
Location: US: west coast, almost. Otherwise, enroute.
|
Let confusion reign or rain. I was seeking clarity.
The MQMD structure has an initial value of -1 EXPIRY_UNLIMITED; so it comes with expiry set to a valid value.
A message consumed will deposit the MQMD with the residual values from the message in the queue. I've seen programmers that did not seed (or reset) the MQMD values when using the same MD for the next put.
_________________
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 |
|
|
| mvic |
| Posted: Fri Feb 05, 2010 1:33 pm Post subject: |
|
|
Jedi
Joined: 09 Mar 2004
Posts: 2080
|
| hdilsky1 wrote: |
| Sorry guys, I am confused now. Max depth of the queue is 5000. The queue gets about 500 expired messages per day (the messages that not picked up by program 1). I want to remove all expired messages. |
This is an important question: how do you know 500 messages are on that queue, and that they are expired?
This is another important question: why is program 1 not picking them up?
| Quote: |
| If I set ExpiryInterval in Windows registry to 300 will the messages in the queue older than 300 sec be removed or not? |
It depends on whether they are expired.
If they are, then yes. If they are not, then no. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Fri Feb 05, 2010 3:23 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9396
Location: US: west coast, almost. Otherwise, enroute.
|
| Quote: |
| This is an important question: how do you know 500 messages are on that queue, and that they are expired? |
Please be specific. For example, did you use some kind of command - like DISPLAY QL() - to determine that there were 500 expired messages?
Why is it important for you to clear the queue? Again, please be specific. Are your applications receiving a Q_FULL ReasonCode?
When an application tries to get one of the 500 messages (that you believe are expired), what happens? What ReasonCode is returned to the application?
_________________
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 |
|
|
| PeterPotkay |
| Posted: Fri Feb 05, 2010 3:30 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7717
|
The Expiry Scavengar process only considers queues that are open, even if only for someting like MQINQ. I fthe queue is not open, it is not "loaded" and thus ignored by the Scavenger. That's the way it behaves on MQ 6, not sure if the same on MQ 7.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| hdilsky1 |
| Posted: Fri Feb 05, 2010 4:55 pm Post subject: |
|
|
Novice
Joined: 04 Feb 2010
Posts: 10
Location: Dallas,TX
|
To mvic
1.This is an important question: how do you know 500 messages are on that queue, and that they are expired? I browsed messages in Local quue and saw messages from yesterday and this morning, which I expected to be removed (total 500). So in few days the queue will be full and receiver channel will be paused. I want to prevent it by removing all old messges.
2.This is another important question: why is program 1 not picking them up? - Well, this is good question. Because the program 1 picks up messages, which came from program 2 in 5 sec after program 1 sent a request (msg). If it came after 5 sec the program 1 ignores them. So, I have 500 messages ignored by program 1 and I want them automatically removed from the queue. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Fri Feb 05, 2010 5:38 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9396
Location: US: west coast, almost. Otherwise, enroute.
|
| Quote: |
| 1.This is an important question: how do you know 500 messages are on that queue, and that they are expired? I browsed messages in Local quue and saw messages from yesterday and this morning, |
If you can browse messages in the queue, they are not expired in the MQ meaning of expired. MQ expires messages whose expiry value in a message descriptor has elapsed - and for no other reason.
Your messages may be expired in a business sense, where your business rules dictate, for example, that a message 2 hours old is too old to process - again, for business reasons.
| Quote: |
2.This is another important question: why is program 1 not picking them up? - Well, this is good question. Because the program 1 picks up messages, which came from program 2 in 5 sec after program 1 sent a request (msg). If it came after 5 sec the program 1 ignores them. So, I have 500 messages ignored by program 1 and I want them automatically removed from the queue. |
[edit] Messages may sit in a queue (and not be processed) for a number of reasons. One common reason: the consuming program was not started.
How is program 1 started? By a timer, for example?
Or, is the queue triggered so that program 1 is started when messages arrive in the queue?
Is this application new?
Has this application worked successfully in the past? If so, what has changed?
Is the program written to MQGET with WaitInterval so that it waits for some time period for additional messages to arrive? Or does the application end when there are no more messages in the queue?
_________________
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 |
|
|
| Vitor |
| Posted: Fri Feb 05, 2010 6:00 pm Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| hdilsky1 wrote: |
| I browsed messages in Local quue and saw messages from yesterday and this morning, which I expected to be removed (total 500). So in few days the queue will be full and receiver channel will be paused. I want to prevent it by removing all old messges. |
Then I was right. You're using the term "expired" in the business sense not the technical sense. Nothing within the software, not ExpiryInterval, not anything, will remove those messages automatically because they're perfectly valid messages (or you wouldn't be able to browse them).
To achieve what you're looking for, the messages must be set to expire by the sender. You'll then almost certainly find that they disappear as expected without changes to any queue manager settings.
Now how hard it is to get the sender to change their code is entirely dependant on your site.
Or you need to fix Program 1 so it doesn't leave messages on the queue, most likely by increasing the wait time. IMHO you're better off setting the expiry as there's always going to be a reply that turns up too late or not at all.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Fri Feb 05, 2010 6:08 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9396
Location: US: west coast, almost. Otherwise, enroute.
|
| Vitor wrote: |
| Or you need to fix Program 1 so it doesn't leave messages on the queue... |
For example, program1 could look at the Context fields of each message, look at the date/time the message was created (put to the queue) to see if it is in or out of the business time rule; then either process the message (if it's within the business time rule) or not process it (ignore it) if it is outside the business rule.
_________________
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 |
|
|
| Vitor |
| Posted: Fri Feb 05, 2010 6:21 pm Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| bruce2359 wrote: |
| Vitor wrote: |
| Or you need to fix Program 1 so it doesn't leave messages on the queue... |
For example, program1 could look at the Context fields of each message, look at the date/time the message was created (put to the queue) to see if it is in or out of the business time rule; then either process the message (if it's within the business time rule) or not process it (ignore it) if it is outside the business rule. |
Yes. I still think it's cleaner to set expiry time though. 
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Fri Feb 05, 2010 7:22 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9396
Location: US: west coast, almost. Otherwise, enroute.
|
I'm thinking that program1 isn't getting triggered...
_________________
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 |
|
|
| Vitor |
| Posted: Fri Feb 05, 2010 8:09 pm Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| bruce2359 wrote: |
| I'm thinking that program1 isn't getting triggered... |
I'm not saying you're wrong. Trigger failure would give a larger %age errors but as we've no information on volumes or indeed what time frame / message rate we're talking about then it's all just speculation. I'm also doubtful that if (as we've been told) program 1 sends a request you'd design it to be triggered by the reply.
My point is the more general one that things being what they are, sooner or later a reply will turn up later or not at all either because the request was delayed or the reply was. So it's better to use expiry to weed these out than to clear up after the event with extended wait times or clean up applications that compare put times to business rules.
Which is not to say either of those methods wouldn't work, or be a better fit with some site rules or situations. Very seldom WMQ provides only 1 good answer.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Fri Feb 05, 2010 10:27 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9396
Location: US: west coast, almost. Otherwise, enroute.
|
I just reread the OP - the post about expiring messages...
It appears that the design is trying to anticipate a failure of one or the other server applications. The requesting app puts a message on q1 to be serviced by program1; and if a reply does not come back in n seconds, then the app puts the same request to another instance of the server q2, serviced by program2. With such little detail about the actual design, I'm guessing that it doesn't contemplate the replicated messages.
My triggering comment was in regards to the server app not coming to life within the n seconds; but the requesting app continues to put request messages.
If I've understood the design (and I'm not sure that I do), this design, like all good request-reply models should keep track of the requests it sent AND the replies it received - and manage any inconsistencies.
I've seen this design (the one I'm suspecting the OP is after) work, where the requesting app puts multiple copies of the same request message to multiple server queues, hoping that one server app replies. The requesting app discards duplicate replies.
_________________
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 |
|
|
| hdilsky1 |
| Posted: Fri Feb 05, 2010 10:29 pm Post subject: |
|
|
Novice
Joined: 04 Feb 2010
Posts: 10
Location: Dallas,TX
|
Thank you all very much. You are absolutely right: the messages in the queue expired in the business sence, but not in technical sence. I need to check with developers, who know nothing about program 1 (all of them relatively new). What I know is that the program 1 picks up some messages and based on the time they arrived (should be less than 5 sec) puts data that has been waiting for the message into the database. It just ignores messages arrived to the local queue later than 5 sec.
Question: Is there in MQ an option (attribute, parameter) that can be setup to clear messages that are expired from business point of view? i saw an attribute timeToLive. Can it help to resolve the problem? |
|
| Back to top |
|
|
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
|
|
