| Author |
Message
|
| gerardmaj |
 Posted: Wed Dec 03, 2008 3:02 am Post subject: Configure MQInput node to receive messages of a certain age |
 |
|
Newbie
Joined: 16 Sep 2008
Posts: 9
|
Hi
Does anyone know if it is possible to configure a MQInput node to only receive messages from a defined MQ queue based on the age of the message. e.g I only want to read messages off the queue that have been on the queue for over 24hrs.
Many thanks |
|
| Back to top |
|
 |
| Vitor |
| Posted: Wed Dec 03, 2008 3:07 am Post subject: Re: Configure MQInput node to receive messages of a certain |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| gerardmaj wrote: |
| Does anyone know if it is possible to configure a MQInput node to only receive messages from a defined MQ queue based on the age of the message |
No it's not.
It's a bit anti-pattern to have messages sitting on a queue for any length of time, particually that length of time. More typically you'd have WMQ monitoring that would notice the lack of movement on the queue and attempt to restart/reboot/reinitialise the process intended to be reading these messages on arrival, and sounding alarms if it won't start.
You could browse the messages off and check put times but that would chew through resources like an American car maker chewing government money. I couldn't recommend it unless there was absolutely no other answer.
If you give us a little on your requirement, perhaps we could evolve another answer....
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| gerardmaj |
| Posted: Wed Dec 03, 2008 3:35 am Post subject: |
|
|
Newbie
Joined: 16 Sep 2008
Posts: 9
|
| Thanks for that. I'll explain my situation - hopefully it makes sense. My scenario here is that I have a flow (1) that puts messages on a queue and specifies a REPLY TO Q to receive a MQRO_COD report. The flow that I was referring to in my original post (2) will read the messages off the output queue specified in my flow (1) and fire the MQRO_COD report to the REPLY TO Q specified. I want to wait for a period time before reading messages of the queue because I have a third flow (3) that checks for unreceived receipts for flow (1) and want to test that it is working. Not sure how clear all that is??? |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Dec 03, 2008 3:43 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
There have been many posts on the forum about COD messages and why they're a bad idea. One of the reasons is how you deal with the COD messages, and tie them back to their requests.
The principle reason they're at least unncessary is that you're paying a large license fee for an assured delivery system. This isn't some TCP/IP based thing where data goes into the space between worlds; all persistent WMQ messages will be delivered and the COD is simply tautological.
Your best bet is to remove the COD messages from the system. They're typcially added to a design only because some management group wanted "certainty", or "belt and braces", not for any good reason. Aside from that, consider starting your clean up flow once every 24 hours with a cron job, Timer node or similar.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| gerardmaj |
| Posted: Wed Dec 03, 2008 3:52 am Post subject: |
|
|
Newbie
Joined: 16 Sep 2008
Posts: 9
|
| Thanks for that. Yes I had considered both timer node and/or cron job. I'll pursue that. I've also noted your comments re COD, and in my case 'belt and braces' was the requirement. I'm afraid I'm stuck with it. |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Dec 03, 2008 4:10 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| gerardmaj wrote: |
| in my case 'belt and braces' was the requirement. I'm afraid I'm stuck with it. |
You have to wonder (in my case out loud in management meetings!) what the thinking is with this. So there's a process that matches COD with requests? If it doesn't match, is it a failure of the request process, a failure of the reconciliation process or a failure of a WMQ component, which could easily mean the requests will actually arrive and be processed after they've been considered "lost" and reproduced. If it's important that all requests are answered, get the requesting application to produce a list of unanswered requests on a 24 hour basis, or ensure you have top quality WMQ monitoring that can spot problems.
Still, what can you do.......?  
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| francoisvdm |
| Posted: Wed Dec 03, 2008 10:38 pm Post subject: |
|
|
Partisan
Joined: 09 Aug 2001
Posts: 332
|
Ahh, the age old COA and COD debate. I find COD VERY convenient to prove that somebody did remove a message from target queue, especially between companies/departments. I do agree that "we" trust MQ to deliver, but the real world out there just does not, and administrators with happy fingers do from time to time mess around even the safest MQ setup.
With a COD message in place the best thing for me is that I can say... "YOU DID RECEIVE AND PROCESS THE MESSAGE", so go away and bug somebody else for "YOUR" problem, I (read MQ) did my job and I can proof it.
And yes, there is this issue if COD gets lost etc etc, but in the real world that is very seldom a problem.
_________________
If you do not know the answer or you get the urge to answer with "RTFM" or "Search better in this forum", please refrain from doing so, just move on to the next question. Much appreciated.
Francois van der Merwe |
|
| Back to top |
|
|
| Vitor |
| Posted: Thu Dec 04, 2008 2:55 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
I have no dispute with the thrust of your post. I simply prefer an effective audit regime of original messages in transit combined with robust monitoring & QA of WMQ. Fewer moving parts as it were.
Monitoring catches any issues with WMQ before anyone else spots them (and goes "Ha ha!" in my direction), robust QA & change control deals with WMQ admins with busy, happy fingers.
QA prevents 95% of dodgy changes, change control ensures that in the other 5% of cases the guilty are found and trouted.
It's whatever works for your site really. As you say, it's an age old debate and is unlikely to reach a conclusion! 
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
|
|
