| Author |
Message
|
| soumen.smn |
 Posted: Mon Jun 11, 2012 1:57 am Post subject: Rolling File Appender using WMB nodes |
 |
|
Novice
Joined: 05 Jan 2012
Posts: 10
Location: Kolkata, INDIA
|
Hi,
Is it possible to implement rolling file appender in WMB using WMB nodes as it is doable using log4j? I do not find any property setting for trace node, file output node etc.
_________________
Thanks!
Soumen |
|
| Back to top |
|
 |
| lancelotlinc |
| Posted: Mon Jun 11, 2012 4:59 am Post subject: |
|
|
Jedi Knight
Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA
|
Trace nodes are simple logging mechanisms that are most helpful in DEV and TEST environments. They do not roll automatically. We disable our Trace nodes in PROD.
You can call log4j directly from any WMB language node: ESQL Compute, Java Compute. .NET Compute, etc. Using log4j, you can use any file appender log4j supports.
_________________
http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER |
|
| Back to top |
|
|
| mqjeff |
| Posted: Mon Jun 11, 2012 7:12 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
it's not like this same question hasn't been asked several times in the last couple of weeks.
Think outside the file!
You have plenty of tools available in broker to provide fast and easy separation of data reporting and data storage.
Log files in general are just an out-of-diskspace error waiting to happen.
There's absolutely no reason to burden your code with the management of rolling log files. Use OS level tools to handle that aspect for you, if you continue to believe in paper-tape solutions.
Or even better, just dump everything to user trace and let broker handle it.
Again, think outside the file! |
|
| Back to top |
|
|
| smdavies99 |
| Posted: Mon Jun 11, 2012 1:10 pm Post subject: |
|
|
Jedi Council
Joined: 10 Feb 2003
Posts: 6076
Location: Somewhere over the Rainbow this side of Never-never land.
|
| mqjeff wrote: |
Or even better, just dump everything to user trace and let broker handle it.
|
Dont use queues for it either (unless you have something removing the messages).
_________________
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 |
|
|
| mqjeff |
| Posted: Mon Jun 11, 2012 1:11 pm Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| smdavies99 wrote: |
| mqjeff wrote: |
Or even better, just dump everything to user trace and let broker handle it.
|
Dont use queues for it either (unless you have something removing the messages). |
You mean, like something that was a standalone java program that used log4j to write out to a rolling log file appender? |
|
| Back to top |
|
|
| smdavies99 |
| Posted: Mon Jun 11, 2012 10:43 pm Post subject: |
|
|
Jedi Council
Joined: 10 Feb 2003
Posts: 6076
Location: Somewhere over the Rainbow this side of Never-never land.
|
| mqjeff wrote: |
You mean, like something that was a standalone java program that used log4j to write out to a rolling log file appender? |
Possibly but it could just as well write the records to a DB or send them to Tivoli or HP OpenView (other similar systems are available)
_________________
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 |
|
|
| mqjeff |
| Posted: Tue Jun 12, 2012 5:15 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| smdavies99 wrote: |
| mqjeff wrote: |
You mean, like something that was a standalone java program that used log4j to write out to a rolling log file appender? |
Possibly but it could just as well write the records to a DB or send them to Tivoli or HP OpenView (other similar systems are available) |
 |
|
| Back to top |
|
|
| zpat |
| Posted: Tue Jun 12, 2012 10:32 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
I think log files are a symptom of the casual approach to development that seems common these days.
I spent my time as a developer without ever using a log file. I simply made sure my code worked properly. |
|
| Back to top |
|
|
| smdavies99 |
| Posted: Tue Jun 12, 2012 10:45 am Post subject: |
|
|
Jedi Council
Joined: 10 Feb 2003
Posts: 6076
Location: Somewhere over the Rainbow this side of Never-never land.
|
| zpat wrote: |
I spent my time as a developer without ever using a log file. I simply made sure my code worked properly. |
There are quite a few situations where Audit requirements mean that 'everything' is logged.
A comprehensive logging and autiting environment can also help support issues. The code might not be at fault but what about the times when your flow receives total garbage means that the broker team do not have to spend days/weeks etc trying to tell a developer that they are sending rubbish. Having the evidence of this is invaluable.
Obviously if you have worked in an environment where the quality of the data being processed is 1,000,000% accurate then great. But as with all IT systems, 'the computers don't make mistakes, humans do'
_________________
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 |
|
|
| mqjeff |
| Posted: Tue Jun 12, 2012 10:47 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| smdavies99 wrote: |
| zpat wrote: |
I spent my time as a developer without ever using a log file. I simply made sure my code worked properly. |
There are quite a few situations where Audit requirements mean that 'everything' is logged. |
There are also quite a few situations where the meaning of 'working properly' is extremely poorly defined.
In absence of solid requirements, it can be difficult to produce code that matches those requirements.
Some kind of logging/auditing of the process can be used to show "this is *why* the code produced that result, which you didn't tell me was the wrong result" |
|
| Back to top |
|
|
| zpat |
| Posted: Tue Jun 12, 2012 10:50 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
Computers think in binary. Precise requirements are a pre-requisite for programming them. Then it either works properly or it doesn't.
Learning to program in Assembler is a good training for the mind. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Tue Jun 12, 2012 11:51 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| zpat wrote: |
Computers think in binary. Precise requirements are a pre-requisite for programming them. Then it either works properly or it doesn't.
Learning to program in Assembler is a good training for the mind. |
I've coded in Assembler.
I have a very different view.
The code always works correctly. In that it always does exactly what it says it will do. The difficulty comes in when you think it does something different than what it says it will do.
There are lots of valid reasons why the waterfall method that requires full and complete specification of all requirements before any code is written has been phased out.
It did have the advantage in that one could write code that met the requirements without having to make educated guesses. It had the severe disadvantage in that you spent most of your time writing requirements, and not much time writing code. Am I a business analyst? Or a programmer? |
|
| Back to top |
|
|
| Vitor |
| Posted: Tue Jun 12, 2012 12:02 pm Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| zpat wrote: |
| Learning to program in Assembler is a good training for the mind. |
When the mind that needs training is the business analyist's, it's no use at all. My personal experience with assembler programing is that it trained me to carry migraine medication at all times.
Assembler was good training back in the day. In this modern world of dancing widgets and massive memory, those days are gone & we must salvage what we can of them: source code control, repeatable testing and implementation procedures, all sadly slipping away in a wave of Agile and requirements that start "we'll going to sell a new product, features to be determined in a later iteration".
Logging is all that saves us from this modern definition of "working" by transmuting it into "working like you said it should".
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| lancelotlinc |
| Posted: Tue Jun 12, 2012 12:03 pm Post subject: |
|
|
Jedi Knight
Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA
|
| mqjeff wrote: |
| one could write code that met the requirements without having to make educated guesses. |
My current assignment is the most agile, most opaque assignment I have ever been on. We sometimes don't have any specs, and rely on word-to-mouth from business analysts to code something that behaves the way they want. We end up stubbing alot of stuff out and relying on Rational Service Tester to point out what doesn't meet the verbal requirements.
http://www.ibm.com/developerworks/rational/products/tsq/
_________________
http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER |
|
| Back to top |
|
|
| deepnair |
| Posted: Tue Jun 12, 2012 1:53 pm Post subject: |
|
|
Apprentice
Joined: 07 Feb 2012
Posts: 35
|
zpat
| Quote: |
I think log files are a symptom of the casual approach to development that seems common these days.
I spent my time as a developer without ever using a log file. I simply made sure my code worked properly.
|
I just simply dont believe the one said above... if the code is simple and straight forward it may be possible but i have been in envs where each esql or jcn code has 800+ business use cases - multiple behavior patterns - trace files or log files are very very handy and helpful in such cases.. |
|
| Back to top |
|
|
|
|
