| Author |
Message
|
| mkza.swe |
 Posted: Mon Jun 04, 2012 10:27 am Post subject: Logging and Error handling |
 |
|
Novice
Joined: 04 Jun 2012
Posts: 16
|
Hi!
I am looking to develop some decent standard logging and error handling for a series of message flows with WMB V7. I have run into a series of problem, that I have yet to find answers to.
I am thinking of a file per message flow recording different important things. Like INFO messages recording some simple details of received and sent messages, and some ERROR messages to capture errors. The organization that will handle the flows later require it to be very simple to access and read, without MQ/MB knowledge, so a file log would probably be preferred.
I find that both trace nodes and file output nodes have limitations.
Trace node works great for almost all of my requirements, but I would like to customize the file name/path by date and/or ExecutionGroup/Message flow name. It seems it's not possible to use properties like ${SQL.ExecutionGroupLabel}, CURRENT_TIMESTAMP or other xml/environment variables in filename or path, or even define it by user defined properties?
FileOutputNode is great with file name and path customizability but it does not seem to have the option to append to a file, so then can not be used for a standard log.
I have also looked at Log4J, but it seems there has not been an update to the stable release of the Log4J framework for about 2 years, and it only supports java 1.4 (maybe I don't need more, but it seems like an outdated product. Should I be afraid to be left with a custom software without updates in the future?). The Log4J node I'm not sure about either, since it's also based on same old Log4J, and not supported by IBM?)
Question 1: What is a good way to do above mentioned logging in Message Broker? Do you have any recommendations? Do I have to write my own Java-logger with a FileWriter to get this functionality or is there some better way built-in or via supportpac or other product?
Also on Error handling:
Question 2: Is there a way to read/utilize the backout threshold of a queue from within the Message Broker flow?
I can read the Backout Count from the MQMD header, but not the threshold. I would like to take different action in my message flow in my error handling path depending on the backout threshold. If threshold is not reached, I'll just log the problem to the warnings log and rethrow the exception to have it retried. But if the backout threshold is reached, and the message will be backed out, I would like to take other action, like writing to error log or sending an email to an admin. Is this not possible?
Question 3: If above is not possible, are there some other good ways of doing similar way or other good ways of handling unexpected runtime errors? |
|
| Back to top |
|
 |
| lancelotlinc |
| Posted: Mon Jun 04, 2012 10:39 am Post subject: |
|
|
Jedi Knight
Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA
|
Answer 1: We use log4j to write log messages from both ESQL and Java Compute nodes. Our production systems have had no difficulty with log4j. Expressly do not recommend using the IAM3 support pack. You can call log4j directly without it.
Answer 2: Yes, you can retrieve the attributes of a queue.
Answer 3: Do not over-design your error handling. KISS. 97 percent of your effort should focus on happy path development. If you spend more than 3 percent of your effort on error handling, you are doing something wrong.
_________________
http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER |
|
| Back to top |
|
|
| mqjeff |
| Posted: Mon Jun 04, 2012 10:50 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
Use the ESQL LOG statement. This fully allows you to specify every piece of meta data about a given message that you would like to specify.
Use normal filtering on system logs to redirect the output of these statements to individual locations based on the metadata that has been produced.
Then you don't have to code your flow to take different actions based on the severity or nature of the event your flow has issued. You properly put that in your monitoring tools. So for example, you can add the backout count of the message to the event you log, and then your monitoring tool can understand and correlate that with the backout threshold on the queue in question.
Or write your messages to a queue and write a process that will read that queue and write to relevant files.
This is at least as reliable as directly writing to a file in the first place. |
|
| Back to top |
|
|
| whydieanut |
| Posted: Mon Jun 04, 2012 11:35 pm Post subject: |
|
|
Disciple
Joined: 02 Apr 2010
Posts: 186
|
We're looking at options to log Audit and Error data into files too and were considering Log4j as well. But turns out we could not get the required approvals to use a it on production.
Given this, what other options are there for logging into files?
I am looking at using Trace Nodes at the moment.
Any comments? |
|
| Back to top |
|
|
| mqjeff |
| Posted: Tue Jun 05, 2012 2:51 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
STOP THINKING ABOUT LOGGING INTO FILES.
Think about two separate tasks.
- Enabling flows to emit log messages
- enabling a process to receive those log messages and store them somewhere
.
This is exactly what log4j, and it's successors, do. The business code calls a method to emit a message. The log4j framework accepts that message and does whatever you've configured it to do.
So think about the entire issue that way. Then you can make some progress. |
|
| Back to top |
|
|
| inMo |
| Posted: Tue Jun 05, 2012 5:01 am Post subject: |
|
|
Master
Joined: 27 Jun 2009
Posts: 216
Location: NY
|
| Quote: |
| Answer 2: Yes, you can retrieve the attributes of a queue. |
What is your recommendation for inspecting the backout threshold setting of an MQ Queue?
| Quote: |
| Answer 3: Do not over-design your error handling. KISS. 97 percent of your effort should focus on happy path development. If you spend more than 3 percent of your effort on error handling, you are doing something wrong. |
I understand the spirit of the statement, agree with the KISS model, but IMHO the suggestion that 3% of time should focus on error handling is really not enough. |
|
| Back to top |
|
|
| lancelotlinc |
| Posted: Tue Jun 05, 2012 5:12 am Post subject: |
|
|
Jedi Knight
Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA
|
@inMo
I don't really think it is necessary to inspect these attributes, but if you must, it can be done from a JCN. You can do it once, on Initialization, not every message.
I'm not sure why someone would invest so much time in error processing. We connect our Failure terminals, our Catch terminals to a common error flow, capture the original payload, and MQOutput that data to a queue. Later, a human inspects the data and the reason why the transaction failed, and resubmits the data, after possibly editing the content to correct a data problem or asking the SysAdmins to correct a system problem.
Once the original common error handler was written, we spend no time on it, just hook it up to our flows as we go along. 99.999 percent of our time is now spent on real business function and not infrastructure construction, as the WMB product is intended to enable us to do.
_________________
http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER |
|
| Back to top |
|
|
| smdavies99 |
| Posted: Tue Jun 05, 2012 5:23 am Post subject: |
|
|
Jedi Council
Joined: 10 Feb 2003
Posts: 6076
Location: Somewhere over the Rainbow this side of Never-never land.
|
| lancelotlinc wrote: |
I'm not sure why someone would invest so much time in error processing. We connect our Failure terminals, our Catch terminals to a common error flow, capture the original payload, and MQOutput that data to a queue. Later, a human inspects the data and the reason why the transaction failed, and resubmits the data, after possibly editing the content to correct a data problem or asking the SysAdmins to correct a system problem.
[/b]. |
Obviously if the nature of the data you are processing does not fit this model then something slightly different can be chosen.
for example, if the majority of your data is transient in nature and does not contain financial data then a different approach to error handling and reply can be used.
There is no 'one size fits all' design.
_________________
WMQ User since 1999
MQSI/WBI/WMB/'Thingy' User since 2002
Linux user since 1995
Every time you reinvent the wheel the more square it gets (anon). If in doubt think and investigate before you ask silly questions. |
|
| Back to top |
|
|
| lancelotlinc |
| Posted: Tue Jun 05, 2012 5:29 am Post subject: |
|
|
Jedi Knight
Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA
|
| smdavies99 wrote: |
| lancelotlinc wrote: |
I'm not sure why someone would invest so much time in error processing. We connect our Failure terminals, our Catch terminals to a common error flow, capture the original payload, and MQOutput that data to a queue. Later, a human inspects the data and the reason why the transaction failed, and resubmits the data, after possibly editing the content to correct a data problem or asking the SysAdmins to correct a system problem.
[/b]. |
Obviously if the nature of the data you are processing does not fit this model then something slightly different can be chosen.
for example, if the majority of your data is transient in nature and does not contain financial data then a different approach to error handling and reply can be used.
There is no 'one size fits all' design. |
Agree -- while the design can be different, I stand by my original statement: if you spend more than three percent of your resources building error infrastructure, you are doing something wrong.
_________________
http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER |
|
| Back to top |
|
|
| inMo |
| Posted: Tue Jun 05, 2012 5:40 am Post subject: |
|
|
Master
Joined: 27 Jun 2009
Posts: 216
Location: NY
|
I figured you were suggesting something like a JCN. Just wanted to make sure I wasn't missing an attribute in LocalEnvironment or something simple like that. Any idea why almost all queue atrributes are available except that one? It's quite painful at times.
Regarding time, I don't think you and I are that far apart. I agree that a common error handler is a good idea. It is also an investment of time.
But the original question did not assume the existence of a common error handler. So, If 3 weeks were dedicated to flow design and development (120 hrs), 3% equates to 3 1/2 hours. 3 1/2 hours can only qualify as an after-thought. |
|
| Back to top |
|
|
| lancelotlinc |
| Posted: Tue Jun 05, 2012 5:54 am Post subject: |
|
|
Jedi Knight
Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA
|
There is an error handler sample included with Toolkit V7 that can be imported, built and deployed in about three minutes.
_________________
http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER |
|
| Back to top |
|
|
| inMo |
| Posted: Tue Jun 05, 2012 6:19 am Post subject: |
|
|
Master
Joined: 27 Jun 2009
Posts: 216
Location: NY
|
| And there it is - the difference of what constitutes error handling in our respective books. |
|
| Back to top |
|
|
|
|
