| Author |
Message
|
| Hyatt |
 Posted: Fri Aug 23, 2002 9:44 am Post subject: Expired message stuck in transmit Q? |
 |
|
Newbie
Joined: 23 Aug 2002
Posts: 2
|
Scenario:
Sending from MQ 5.2 NT/4.0 to OS/390 MQ 5.2 over classic SVR/RQSTR TCP pairs. Channels in run status, sample amqsput/get from NT to os/390 back to NT successful.
The xmit q to the mainframe that is on the NT box shows a q depth of 1 through the MQ EXP GUI and runmqsc command prpt. The messages cannot be viewed because it is expired, and the xmit q cannot be cleared because: the MCA has the channel open and a process running against the open xmit q with production traffic. DISCINT interval on the channel is 5 minutes and there will be continous traffic across the channel.
Question:
When will a destructive get be done against the xmit q by the MCA that will remove the expired message?  |
|
| Back to top |
|
 |
| PeterPotkay |
| Posted: Fri Aug 23, 2002 10:46 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
Are you sure its an expired message? I would bet it is uncomitted message put by an application on the NT box to a remote queue def.
An expired message would be cleaned up the very next time a message went thru.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| Hyatt |
| Posted: Fri Aug 23, 2002 11:27 am Post subject: expired in xmit q |
|
|
Newbie
Joined: 23 Aug 2002
Posts: 2
|
| 90% sure it is exprired because the sending is a java web app sending request to a message broker on the mainframe that handles routing, the requests have expiry set for 20 seconds |
|
| Back to top |
|
|
| jc_squire |
| Posted: Sun Aug 25, 2002 6:20 pm Post subject: |
|
|
Centurion
Joined: 14 Apr 2002
Posts: 105
Location: New Zealand
|
an expired message would not be cleaned up the very next time a message goes through - have seen this on a customer site where we had to develop a solution to cater for the building up of expired messages. The following from the information centre:
Quote
After a message's expiry time has elapsed, it becomes eligible to be discarded by the queue manager. In the current implementations, the message is discarded when a browse or nonbrowse MQGET call occurs that would have returned the message had it not already expired. For example, a nonbrowse MQGET call with the MatchOptions field in MQGMO set to MQMO_NONE reading from a FIFO ordered queue will cause all the expired messages to be discarded up to the first unexpired message. With a priority ordered queue, the same call will discard expired messages of higher priority and messages of an equal priority that arrived on the queue before the first unexpired message.
A message that has expired is never returned to an application (either by a browse or a non-browse MQGET call), so the value in the Expiry field of the message descriptor after a successful MQGET call is either greater than zero, or the special value MQEI_UNLIMITED.
Since a message whose expiry time has elapsed may not actually be discarded until later, there may be messages on a queue that have passed their expiry time, and which are not therefore eligible for retrieval. These messages nevertheless count towards the number of messages on the queue for all purposes, including depth triggering.
Unquote
You can always setup a script in the Crontab (Unix) or the windows scheduler on a daily basis to clear the queues after hours when you do not expect any production traffic.
Hope this helps.
Regards
_________________
J C Squire
IBM Certified Specialist - MQSeries |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Wed Aug 28, 2002 3:42 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
If there is an expired message on the XMIT queue and another message is placed there, the MCA has to do a GET to remove the new message. That Get will cause any expired message to be removed, since the MCA will start at the head of the queue and start pulling messages. If it comes across an expired message as it process the XMIT queue, it is discarded.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| jc_squire |
| Posted: Wed Aug 28, 2002 4:40 pm Post subject: |
|
|
Centurion
Joined: 14 Apr 2002
Posts: 105
Location: New Zealand
|
Peter,
Totally agree with you on that one. My appologies - looking back now I am not quite sure why I handled my previous post from that angle ..... 
It addresses the issue of expired messages on the destination queue rather than the xmitq queue. In this scenario the receiving applications GET calls were inadequate to do a destructive read on the expired message.
Regards
_________________
J C Squire
IBM Certified Specialist - MQSeries |
|
| Back to top |
|
|
|
|
