| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| Message Expiry Report How2 |
« View previous topic :: View next topic » |
| Author |
Message
|
| mikiu |
 Posted: Fri Jan 07, 2011 1:16 pm Post subject: Message Expiry Report How2 |
 |
|
Acolyte
Joined: 23 Jul 2002
Posts: 61
Location: toronto
|
Can any of yous lerned and helpful gentlefolks give me a brief how-to (or alternately point me to an example) of setting up message expiry reporing (I need MVS and AIX C and JMS)? Infocentre did not yield a lot of info
Our current relationship with an external partner reached the finger pointing stage where we must show each other that the "message made it to you and expired there".
It is unpleasant and I was charged with putting code in place to trace expiry ...
I am grateful for you sharing your wisdom with me/us
Ciao,
Miki |
|
| Back to top |
|
 |
| bruce2359 |
| Posted: Fri Jan 07, 2011 1:20 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
The app that creates the message need to ask for a report message in the MQMD. Take a look at the WMQ Application Programming Reference manual for MQRO_EXPIRY.
If the app msg expires, and MQRO_EXPIRY is specified, then a report message will be sent to the reply-to-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 |
|
|
| fatherjack |
| Posted: Fri Jan 07, 2011 2:00 pm Post subject: |
|
|
Knight
Joined: 14 Apr 2010
Posts: 522
Location: Craggy Island
|
| bruce2359 wrote: |
The app that creates the message need to ask for a report message in the MQMD. Take a look at the WMQ Application Programming Reference manual for MQRO_EXPIRY.
If the app msg expires, and MQRO_EXPIRY is specified, then a report message will be sent to the reply-to-queue. |
Indeed this is how report options can be used to report on expired messages but I'm not sure it tells you where the message was when it expired, just that it did expire. Not used report options much so happy to be proven wrong here. So the OP's requirement to prove/disprove
| Quote: |
| "message made it to you and expired there". |
might not be met by this solution.
Some form of message tracking solution (e.g. TransactionVision or custom message auditing) might be needed to do this.
_________________
Never let the facts get in the way of a good theory. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Fri Jan 07, 2011 3:53 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
The wonder of msg expiry...
_________________
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 |
|
|
| fatherjack |
| Posted: Fri Jan 07, 2011 4:12 pm Post subject: |
|
|
Knight
Joined: 14 Apr 2010
Posts: 522
Location: Craggy Island
|
| bruce2359 wrote: |
| The wonder of msg expiry... |
And inter-company commercial relationships !!!!!
_________________
Never let the facts get in the way of a good theory. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Sat Jan 08, 2011 9:33 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
[edit]
There are no qmgr, queue, or other expiry controls available to a WMQ system admin. Once an app has put a message to a queue, the expiry interval decrements. Once the expiry interval has elapsed, the message is no longer available to any consuming application. If the application requested an expiry report message, one will be sent to the reply-to-queue that the requesting app specified.
[/edit]
| Quote: |
| It is unpleasant and I was charged with putting code in place to trace expiry ... |
This gets to the fundamental question of the relative value of expiring a message.
Let's start with the premise that a message == (exactly equals) a transaction.
If a message is, in fact, a transaction, then I'd expect (require) that the application that initiated the transaction be responsible for expiring the transaction. Time-of-day and timers are readily available in all o/s's, so expiring a transaction at the originating application isn't much of a technical challenge. This expiry technique is quite common in web-based shopping-cart applications.
Let's view this in another way: if the transaction data (message) is sent via tape or diskette or paper, should the physical media (the WMQ message equivalent) have a shelf-life, after which the data becomes unusable or unavailable? Usually, no.
The application change I'd suggest is to set a timer in the originating application; and if the reply message doesn't return in n-seconds, let the application expire the transaction.
This gets us back to the often-repeated discussion of a well-behaved application.
A well-behaved requesting application should keep track of request messages that it sent, and replies it received. It should tolerate (deal with) duplicate or missing replies.
A well-behaved replying application should keep track of request messages that it received, and replies it sent back. It should tolerate (deal with) duplicate or missing request messages.
In summary, a well-written application should not require (demand, expect) that the transport mechanism (WMQ) expire messages.
It's an application design choice.
_________________
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 |
|
|
| mikiu |
| Posted: Sat Jan 08, 2011 5:26 pm Post subject: |
|
|
Acolyte
Joined: 23 Jul 2002
Posts: 61
Location: toronto
|
I am much obliged for your thoughts ... by way of explanation/excuse: I am a big fan of messages expiring: no need for elaborate clean-up procedures and avoids the Monday morning email from MQ admin: "You got 12,689 messages on the XXX.Reject.Queue, do you still need them?". But management is so set to find a culprit and "was it them or us, can you prove that we sent them the message, can you prove the message made it there/here, when, how long did it take?" that they want audit trails and traces and expiry reports that require more code than the business functionality itself ... you been there, no need to elaborate.
See you around when sanity returns
Miki |
|
| Back to top |
|
|
| mvic |
| Posted: Sat Jan 08, 2011 5:43 pm Post subject: Re: Message Expiry Report How2 |
|
|
Jedi
Joined: 09 Mar 2004
Posts: 2080
|
| mikiu wrote: |
we must show each other that the "message made it to you and expired there"
...
I was charged with putting code in place to trace expiry ... |
Sounds to me like your business doesn't really want those messages to expire.
Or maybe I don't get enough of the detail? (I'm not asking you for more details by the way).
IMHO, if you're arguing about where the messages were when they expired, then the mere fact they expired is a problem.
If you stop them expiring, no-one can say "I didn't get the message because it expired before it got to me". |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Sat Jan 08, 2011 5:54 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
Which will be the bigger problem for you (politically)? Messages not consumed left in queues? Or messages mysteriously disappearing (expiring)?
A major supporter of this website offers channel exits that can, as messages arrives/leaves, an image of the message is captured to a sequential file.
When your clients complain that you've lost messages, you can browse the sequential file looking for evidence. Of course, your client will need to provide you with date, time, applicid, and other information unique to the message that seems to be missing.
Here's a best-practice: if messages are important, they should not expire.
_________________
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 Jan 08, 2011 11:52 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
another best practice: if the messages are important, they should be persistent.
Remember that the behavior of the channel is different with persistent and non persistent messages, should a tcp/ip hickup happen.
Have fun 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| exerk |
| Posted: Sun Jan 09, 2011 5:08 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| bruce2359 wrote: |
| ...When your clients complain that you've lost messages... |
Ask them to prove they ever existed in the first place 
_________________
It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys. |
|
| 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
|
|
|
|
