| |
|
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
|
| hdilsky1 |
 Posted: Fri Feb 05, 2010 10:41 pm Post subject: |
 |
|
Novice
Joined: 04 Feb 2010
Posts: 10
Location: Dallas,TX
|
to bruce 2359. OK let me describe the process: The end user entered data that is in memory. The program 1 sends a message to program 2. The program 2 sends verification message to local queue. If verification message put in the queue in 5 sec or less then the program 1 picks up the message and the users' data transmitted to database. If the verification message sent by program 2 arrived to local queue after 5 sec than the message was ignored by program 1 and it should be removed. I thought ExpiryInterval would do the job, but as vital and other experts explained it would not. So, what can be the solution - timeToLive attribute? - Thanks.
It's a little frustrating. |
|
| Back to top |
|
 |
| bruce2359 |
| Posted: Fri Feb 05, 2010 10:57 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
| Quote: |
| It just ignores messages arrived to the local queue later than 5 sec. |
So, the program gets a message from the queue, and if it's older than 5 seconds, it places it back into the queue? The default behavior of the MQGET call is to do a destructive read of a message. There is a browse option (not the default) that does not destroy a message. There is no MQ method that ignores a message.
| Quote: |
| Question: Is there in MQ an option (attribute, parameter) that can be setup to clear messages that are expired from business point of view? |
No. Processing messages based on the content of the message (MQMD or application data payload) is the responsibility of application programs.
| Quote: |
| i saw an attribute timeToLive. Can it help to resolve the problem? |
Time to live is another term for expiry. But, again, it is the responsibility of the application to set this for each message.
| Quote: |
| It's a little frustrating. |
Bad application design or bad programming usually brings grief to sysadmins.
_________________
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: Sat Feb 06, 2010 6:35 am Post subject: |
|
|
Jedi
Joined: 09 Mar 2004
Posts: 2080
|
| hdilsky1 wrote: |
| If the verification message sent by program 2 arrived to local queue after 5 sec than the message was ignored by program 1 and it should be removed. I thought ExpiryInterval would do the job |
In my humble opinion, there are 2 options:
1. Use Expiry on the messages. When the message expires, the message ceases to be gettable, and the queue manager will (at some point thereafter) remove it permanently from the queue.
2. Re-write Program 1 to do something with the "too old" messages:
Example a: Put them to a "too old" queue for audit/exception processing by a new Program 1a.
Example b: If no audit/exception processing is needed, Program 1 could just MQGET the "too old" message, which will remove it.
Note that the above 2 choices both imply changes to the application. But not to the queue manager or the queue.
Hope this helps
Last edited by mvic on Sat Feb 06, 2010 6:59 am; edited 1 time in total |
|
| Back to top |
|
|
| Vitor |
| Posted: Sat Feb 06, 2010 6:36 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| hdilsky1 wrote: |
| 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. |
As my most worthy associate has expounded, this is an odd and very silly design. By default a message read from the queue is removed from the queue. To achieve what you're describing program 1 must be explictly browsing for a messages, checking their business data and then browsing for the next if it doesn't match. This is a hideously inefficient way of reading a queue as the browse cursor must be reset each time. In your case it will read the 1st 500 messages on each pass before checking the next one. This can quite easily lead to a situation where it will take the 5 seconds to reach the first new message so it too will be ignored as too old! Once that happens no more messages will be read & your queue will fill.
| hdilsky1 wrote: |
| 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? |
Yes. It's the attribute I and others have been discussing the length of this post. Try looking it up in the product documentation rather than just looking at the attributes of the message object.
Another, quicker, simpler solution would be for program 1 to do a standard destructive read (again as my associate has indicated) and then just discard messages that are outside the time frame.
I also note your use of the term "verification messages". Slightly off topic, but do these messages contain data that program 2 supplies in reply to program 1's request or just verify that program 2 has received the request? If the later, there are a number of discussions in this forum on why that's a bad idea.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| Vitor |
| Posted: Sat Feb 06, 2010 6:38 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| hdilsky1 wrote: |
| as vital and other experts explained it would not |
That's the 2nd time you've misspelt my name or attempted some odd humour. I'm not vital; in any sense of the word. 
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Sat Feb 06, 2010 7:37 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
| Quote: |
| If the verification message sent by program 2 arrived to local queue after 5 sec than |
As described in the WMQ APR manual, MQ supports four message-types (MQMD_MSGTYPE)
1. REQUEST
2. REPLY
3. REPORT
4. DATAGRAM
So, your use of verification message implies that your app is creating a message where the business rule requires some kind of acknowledgment from program1 to program2.
The usual request-reply model has the requesting program create a REQUEST message (one of the four msgtypes), put it to the request queue; and for the replying program to get the request message, then return a reply message to a named ReplyToQueue that Program1 created just for this purpose. Program1 waits for the reply.
Is this what your design does?
_________________
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 |
|
|
| fjb_saper |
| Posted: Sat Feb 06, 2010 11:37 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| 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.
If I set ExpiryInterval in Windows registry to 300 will the messages in the queue older than 300 sec be removed or not? |
No this is not how expiry works.
IF THE EXPIRY IS SET ON THE MESSAGE to 300 sec, then the NEXT MQGET on the queue would remove the EXPIRED MESSAGES.
IN CASE THE QUEUE IS NOT SERVICED THE BACKGROUND PROCESS WILL REMOVE EXPIRED MESSAGES.
HOWEVER FOR THIS TO WORK THE MESSAGES MUST BE SET TO EXPIRE. This is set by the sender.
It looks like to me that you have a reply to queue that gets messages after the wait time of the requester is over. You did not specify whether the requests were persistent or could be set to expire...
Worst case assumption the reply messages cannot be set to expire:
As there do not seem to be many, just write a little program that does a destructive MQGET, with no wait, of any message on the reply to queue and run it once a day when convenient. This would get rid of the unwanted messages.
Hope this helps 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| Vitor |
| Posted: Sun Feb 07, 2010 6:51 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| fjb_saper wrote: |
| As there do not seem to be many, just write a little program that does a destructive MQGET, with no wait, of any message on the reply to queue and run it once a day when convenient. This would get rid of the unwanted messages. |
This too would work.
This also demonstrates there are many possible solutions to this issue, and selecting the correct one requires knowledge of the local conditions, site standards, which program can or cannot be changed, etc, etc, etc. You could equally use non-persistent messages & temporary queues.
But none of these solutions involve qm.ini or the queue manager settings! 
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| hdilsky1 |
| Posted: Sun Feb 07, 2010 12:27 pm Post subject: |
|
|
Novice
Joined: 04 Feb 2010
Posts: 10
Location: Dallas,TX
|
| To Vitor. Sorry, for misspelling your name (twice). In no way I thought to jumor on it. The only goal for me was to get the problem resolved because it's a prod problem and now I clear out local queue manually. I'll try the options recommended. Thank you so much and again I ppolodgize for everything I did during this discussion. This was my first question ever in this forum. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Sun Feb 07, 2010 2:25 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
| Quote: |
| I apologize for everything I did during this discussion. This was my first question ever in this forum. |
There is no need to apologize. And you did pretty well with your first post.
Please consider that there is a difference between a symptom, and the problem that caused the symptom.
Your symptom was messages remaining in the queue beyond their useful business life. Unprocessed messages in the queue is a symptom of an underlying problem - or problems.
Again, continue to post. Even if you misspell a name or two, we won't be angry.
_________________
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: Sun Feb 14, 2010 2:41 pm Post subject: |
|
|
Novice
Joined: 04 Feb 2010
Posts: 10
Location: Dallas,TX
|
| Thank you all very much. It's a great forum. |
|
| 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
|
|
|
|
