| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| Message Expiry in Cluster TxQ |
View previous topic :: View next topic |
| Author |
Message
|
| Shalini |
 Posted: Mon Dec 27, 2004 2:03 am Post subject: Message Expiry in Cluster TxQ |
 |
|
Master
Joined: 30 Apr 2002
Posts: 224
Location: India
|
Hi,
MQ5.3 CSD5 WinNT & Solaris
For our MQCluster Env we have a requirement that we set the message expiry for the messages before putting to image of the cluster queue. If we get a expiry report we send that message again to destination Cluster QMGR (All in same cluster).
If all the destination cluster channel is stopped or all the destination QMGR is down (All QMGR in same Cluster), then the messages expires in the current QMGR TxQ (Cluster.txQ) , but I don’t get the expiry report for the messages expiring in TxQ (Cluster.txQ).
For all the messages which pass thro the TxQ (ie System.ClusterTxQ)
Even IF I open the messages in the Explorer the time of the messages goes on decrementing and once it expires, I don’t get the expiry in ReplyToQMGR and ReplytoQ.
But when network and channel are healthy then the messages expire in the destination cluster queue for which I get the expiry report in “ReplyToQMGR” and “ReplyToQ”
So can I conclude that the message if expires in the local cluster queue of destination QMGR, then the expiry report is sent to my QMGR and if message expiring in TxQ (System.cluster.TxQ) of my QMGR ,then it will be not.
Hence, they are lost as I will not send the messages as I donot get the expiry report.
My ReplyToQMGR=’ ’
Reply to Queue =”image cluster queue of MY QMGR local queue”
Please comment.
 |
|
| Back to top |
|
 |
| mq_developer |
| Posted: Mon Dec 27, 2004 10:34 am Post subject: |
|
|
Voyager
Joined: 18 Feb 2002
Posts: 82
|
I think you made a wrong observation .. Remember this expiry messages will be generated only when they are "seen" by an application/process ..
When the messages are lying on XMITQ , if the channel to the remote queue manager where they are intended to is not running.. these messages wont be been 'seen'/read by the channel ... so you wont get a expiry message right after the expiry interval is elapsed , but once the channel tries to pick up the message you will ( hence the reason you observe report messages generated by n/w failures etc .. ) ..
on mvs , there is a attribute & command to sweep for expiry message ... but on UNIX it is not ... |
|
| Back to top |
|
|
| Shalini |
| Posted: Mon Dec 27, 2004 9:25 pm Post subject: |
|
|
Master
Joined: 30 Apr 2002
Posts: 224
Location: India
|
Hi mq_developer,
Thanks for reply.
Can any one suggest me how to tackle this particular fail over scenario.
However, my resend agent will send the message only if its get the expiry messages of particular msgs, but for the messages expiring in Txq I don’t get the expiry report.
How to tackle the situation. 
According to our design we have to make each message with expiry report.
Please suggest/comment
|
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Tue Dec 28, 2004 5:18 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| Quote: |
If a COA, COD, or expiration report message is received at the reply queue, it is guaranteed that the original message arrived, was delivered, or expired, as appropriate. However, if one or more of these report messages is requested and is not received, the reverse cannot be assumed, since one of the following may have occurred:
a. The report message is held up because a link is down.
b. The report message is held up because a blocking condition exists at an
intermediate transmission queue or at the reply queue (for example, the
queue is full or inhibited for puts).
c. The report message is on a dead-letter queue.
d. When the queue manager was attempting to generate the report message, it was unable to put it on the appropriate queue, and was also unable to put it on the dead-letter queue, so the report message could not be generated.
e. A failure of the queue manager occurred between the action being reported (arrival, delivery or expiry), and generation of the corresponding report message. (This does not happen for COD report messages if the application retrieves the original message within a unit of work, as the COD report message is generated within the same unit of work.)
Exception report messages may be held up in the same way for reasons 1, 2, and 3 above. However, when an MCA is unable to generate an exception report message (the report message cannot be put either on the reply queue or the dead-letter queue), the original message remains on the transmission queue at the sender, and the channel is closed. This occurs irrespective of whether the report message was to be generated at the sending or the receiving end of the channel.
|
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| Shalini |
| Posted: Tue Dec 28, 2004 5:27 am Post subject: |
|
|
Master
Joined: 30 Apr 2002
Posts: 224
Location: India
|
Hi PeterPotkay,
Thanks for reply.
Can U please let me know the link/pdf where you got such info.
I have to communicate such issues using proper channels.
|
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Tue Dec 28, 2004 6:44 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
The Application Programming Reference Guide. Good stuff in there.... 
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
|
|
|
|
|
Page 1 of 1 |
|
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
|
|
|
|
