| Author |
Message
|
| idhayham |
 Posted: Thu Jan 29, 2009 1:45 pm Post subject: MQ Series |
 |
|
Novice
Joined: 29 Jan 2009
Posts: 11
|
| I have a system which gets message from upstream applications and forwards that to downstream systems.Is there any possible way i can track the messages recieved and error out if it exceeds a certain limit of seconds.Your help is appreciated. |
|
| Back to top |
|
 |
| Vitor |
| Posted: Thu Jan 29, 2009 2:06 pm Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
Moved to more relevant section
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| Vitor |
| Posted: Thu Jan 29, 2009 2:09 pm Post subject: Re: MQ Series |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| idhayham wrote: |
| if it exceeds a certain limit of seconds. |
If what exceeds a certain limit of seconds?
You could probably do something with confirmation messages and/or put times. This could get messy, especially if the various systems involved do not have their clocks syncronised.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| idhayham |
| Posted: Thu Jan 29, 2009 2:50 pm Post subject: Reply |
|
|
Novice
Joined: 29 Jan 2009
Posts: 11
|
| If the message reply exceeds certain time limit. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Thu Jan 29, 2009 4:52 pm Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
Yes.
You set your Request message to expiry in X+1 seconds, and you set your MQGET options to Wait for X seconds.
Then you will get a 2033 when you do not get your reply within X seconds. |
|
| Back to top |
|
|
| Vitor |
| Posted: Fri Jan 30, 2009 2:20 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
This method does mean that "late" replies are not delivered at all. If all you're trying to do is determine if the replies are inside or outside an SLA (e.g. 80% of all replies within 10 seconds) it may not be entirely suitable.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| zpat |
| Posted: Fri Jan 30, 2009 2:34 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
It's not entirely clear if this is a request/reply design or not.
If it is then allow MQ to wait for the reply (MQGMO_WAIT) for the relevant time interval. To avoid orphaned reply messages (which arrive too late) -- use MQMD expiry time (as has been suggested) on these.
If you are trying to avoid forwarding old messages - you can compare the PUTDATE and PUTTIME to the current date/time before forwarding them. |
|
| Back to top |
|
|
| idhayham |
| Posted: Fri Jan 30, 2009 10:40 am Post subject: |
|
|
Novice
Joined: 29 Jan 2009
Posts: 11
|
Let me give a more clear picture.
Messages come from upstream systems and are placed in local queues of client,my applications picks the messages and puts a copy in HOLD queue(which has a gettime and correlation id) ,messages is then forwarded to downstream systems and the downstream replies back in a reply queue.My applications compares the correlation id and sends back to requested application.
Problem- Some times the channels and triggers are functioning well.But messages are not returning back in SLA time. Need to error out or alarm out when the reply exceeds SLA time. looking for a mouse trap !!! |
|
| Back to top |
|
|
| Vitor |
| Posted: Fri Jan 30, 2009 11:25 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
Ok, some questions arise:
What does your application do, aside from measure times?
Why are you measuring against the time you got from the queue, rather than the time the upstream system (and has been waiting)?
How do you handle replies that don't come at all?
Why are you not simply monitoring the system in the traditional manner to ensure fast & efficient opperation, and to highlight bottlenecks?
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| idhayham |
| Posted: Tue Feb 03, 2009 2:32 pm Post subject: |
|
|
Novice
Joined: 29 Jan 2009
Posts: 11
|
Vitor,
1) It formats into format needed for downstream streams other than calculating.
2)We dont measure time. We just log the times in logs
3)WE dont have mechanism to handle lost orders |
|
| Back to top |
|
|
| idhayham |
| Posted: Tue Feb 03, 2009 2:33 pm Post subject: |
|
|
Novice
Joined: 29 Jan 2009
Posts: 11
|
| And finally , how can it be monitored in traditional methods.Please let me know the methods |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Feb 04, 2009 1:16 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| idhayham wrote: |
| 3)WE dont have mechanism to handle lost orders |
Your business accountants must be so laid back they're horizontal! 
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Feb 04, 2009 1:17 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| idhayham wrote: |
| And finally , how can it be monitored in traditional methods.Please let me know the methods |
All clearly set out in the "Monitoring MQ" manual.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Wed Feb 04, 2009 4:15 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
That mouse trap has already been built and a number of monitoring software vendors are ready to sell it to you... 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
|
|
