| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| Efficient logging mechanism |
« View previous topic :: View next topic » |
| Author |
Message
|
| Pavan Kumar PNV |
 Posted: Wed Nov 19, 2008 6:49 am Post subject: Efficient logging mechanism |
 |
|
Acolyte
Joined: 03 Feb 2007
Posts: 66
|
In an approach to test a typical request-reply scenario, if we were to log the messages flowing across a system that uses MQ server on both ends, can we discuss the options and their efficency? Eg: channel exits ..
_________________
_____________
Pavan Pendyala
http://pavanz.blogspot.com |
|
| Back to top |
|
 |
| Vitor |
| Posted: Wed Nov 19, 2008 6:59 am Post subject: Re: Efficient logging mechanism |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| Pavan Kumar PNV wrote: |
| In an approach to test a typical request-reply scenario, if we were to log the messages flowing across a system that uses MQ server on both ends, can we discuss the options and their efficency? Eg: channel exits .. |
If you have sufficient knowledge to produce channel exits, you don't need to test a request/reply scenario - you'd be able to set up & troubleshoot one in your sleep! Exits are the last resort answer to any problem.
If you're testing a scenario, put the message logging in the applications where it belongs (with a convienient switch so you can turn it off in production) and use the existing WMQ logging to identify problems.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| Pavan Kumar PNV |
| Posted: Wed Nov 19, 2008 7:03 am Post subject: |
|
|
Acolyte
Joined: 03 Feb 2007
Posts: 66
|
I totally agree that this is more like testing MQ rather than the flow of message across MQ, but unfortunately, there is a special validation requirment that we log the messages even as they flow across MQ apart from logging them at the application end. So, if we were to perform this test anyways, what would be the most efficent approach?
_________________
_____________
Pavan Pendyala
http://pavanz.blogspot.com |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Wed Nov 19, 2008 7:08 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
In its role of message transport, MWQ does an excellent job of not losing or duplicating your messages; but applications can and do continue to do both.
To satisfy broader business goals, I'd suggest writing request-reply applications that are themselves sensitive to loss or duplication of data (messages).
Requestor application should keep track of requests it has sent and replies it has received back; while replying applications should keep track of requests it has received and replies it has sent back to the requestor.
This serves the purpose you require (validating the request-reply functionality); and, at the same time, ensure no lost or replicated data, AND meets the usual audit requirements.
_________________
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 |
|
|
| Vitor |
| Posted: Wed Nov 19, 2008 7:11 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| Pavan Kumar PNV wrote: |
| there is a special validation requirment that we log the messages even as they flow across MQ apart from logging them at the application end. |
Validation? What requirement? What details, exactly, need to be captured?
Assuming this is only in test, you could use something like the mirrorq exit to dump a copy of the messages into a spare queue and extract the relevant details.
Note these points well:
- mirrorq is sample code. It's not production strength, not intended to be, and using it like this will give management the false belief they can or should use it in production.
- the exit will affect performance and throughput.
- a problem with the exit will at best reduce throughput to a crawl and at worst bring the queue manager crashing down round your ears.
- because it's a sample, any problems you get will be generally yours to fix. Support may be thin on the ground (another reason why you don't want this in production)
Like I said, exits are a last resort. Push back against this requirement and build it into the endpoints. If you need to log WMQ like this, you need to question why you bothered to buy it! 
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| 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
|
|
|
|
