Author |
Message
|
gag_nm |
Posted: Sat Feb 05, 2011 9:30 pm Post subject: TRACE FILE NOT GETTING CREATED |
|
|
Centurion
Joined: 16 Oct 2008 Posts: 102
|
HI Friends,
In our AIX Environment we have some trace logs which were created by WMB 6.1, i want to take back up of this logs, so i was using below script to take back up.
Quote: |
cp /test/log/TestTrace.txt /test/log/TestTrace_$(date +'%d%m%y').txt |
File was getting created with current date and clearing TestTrace.txt file with cp /dev/null command as shown below.
Quote: |
cp /dev/null /test/log/TestTrace.txt; |
Next time any message comes to WMB ,it was logging to TestTrace.txt.
Someone told me that instead of copying("cp") file you can simple move ("mv")file,it will be faster then copying file.
So i made some changes in script as below
Quote: |
mv /test/log/TestTrace.txt /test/log/TestTrace_$(date +'%d%m%y').txt |
After i was moving file,TestTrace.txt was not getting created even message was passing through Trace node.
If I redeploy the message flow , then TestTrace.txt file was getting created.
Can some please help me how to solve this with out redeploying flow. |
|
Back to top |
|
 |
mqjeff |
Posted: Sun Feb 06, 2011 11:44 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008 Posts: 17447
|
Someone told you the wrong thing, when they said you could move a file that was actively being written to. |
|
Back to top |
|
 |
madi |
Posted: Mon Feb 07, 2011 11:05 am Post subject: |
|
|
 Chevalier
Joined: 17 Jan 2006 Posts: 475
|
you shd probably add code to stop the message flow before the move and then start it again _________________ IBM Certified Solutions Developer - WMB 6.0 |
|
Back to top |
|
 |
joebuckeye |
Posted: Mon Feb 07, 2011 11:49 am Post subject: |
|
|
 Partisan
Joined: 24 Aug 2007 Posts: 365 Location: Columbus, OH
|
Quote: |
Someone told me that instead of copying("cp") file you can simple move ("mv")file,it will be faster then copying file. |
Moving a file on UNIX type OSes will be faster than a copy as long as the move is to a directory on the same file system. If the move is to another file system then the system is basically doing a copy then delete under the covers.
As Jeff mentioned, the broker has an open file handle to that trace file. You may move the file and it may not appear in your file listing of that directory but because the broker still has the file open it is not really deleted. The file is not truly deleted until the broker releases its handle to that file. The broker releases its file handle when either it is stopped or restarted (via flow deployment).
So if you don't want to be restarting the flow every time you grab that trace file you will need to do the two copy commands, copy to get the contents and then copy to "clear" the file out.
BTW, how do you keep from losing any trace messages between the two copy commands? Depending on how much traffic the flow has and how big the trace file is it could be significant.
I don't believe trace nodes are really a good solution for logging in the broker, they are more for debugging purposes. |
|
Back to top |
|
 |
smdavies99 |
Posted: Mon Feb 07, 2011 1:47 pm Post subject: |
|
|
 Jedi Council
Joined: 10 Feb 2003 Posts: 6076 Location: Somewhere over the Rainbow this side of Never-never land.
|
joebuckeye wrote: |
I don't believe trace nodes are really a good solution for logging in the broker, they are more for debugging purposes. |
Yet many sites insist on using them widely even in Production. _________________ 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 |
|
 |
fatherjack |
Posted: Tue Feb 08, 2011 2:02 am Post subject: |
|
|
 Knight
Joined: 14 Apr 2010 Posts: 522 Location: Craggy Island
|
smdavies99 wrote: |
joebuckeye wrote: |
I don't believe trace nodes are really a good solution for logging in the broker, they are more for debugging purposes. |
Yet many sites insist on using them widely even in Production. |
What if we need to debug a production problem ? _________________ Never let the facts get in the way of a good theory. |
|
Back to top |
|
 |
smdavies99 |
Posted: Tue Feb 08, 2011 3:12 am Post subject: |
|
|
 Jedi Council
Joined: 10 Feb 2003 Posts: 6076 Location: Somewhere over the Rainbow this side of Never-never land.
|
good point.
So you have them configurable (which we do)
But.............
When the logfile gets rather large (>1Gb) does its purpose become rather irrelevant? How useful is that to find a critical problem?
I've seen systems where everything in and out is logged to a file AND to a Database AND all in incoming message are store in BLOB form in another DB.
Yet all the support people seem to do is spend their time wading through GB of trace logs.
Your testing should give you the confidence that if there are errors in Production then the problem lies in the Data. So take the input message and replay it on a test system to your hearts content.
Don't start running usertrace on a live system especially where that is the only live server you have...
Yeah, I know I'm banging my head against a brick wall here. _________________ 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 |
|
 |
fatherjack |
Posted: Tue Feb 08, 2011 3:17 am Post subject: |
|
|
 Knight
Joined: 14 Apr 2010 Posts: 522 Location: Craggy Island
|
smdavies99 wrote: |
good point.
So you have them configurable (which we do). |
Correct
smdavies99 wrote: |
I've seen systems where everything in and out is logged to a file AND to a Database AND all in incoming message are store in BLOB form in another DB.
Yet all the support people seem to do is spend their time wading through GB of trace logs. |
Me too.
smdavies99 wrote: |
Yeah, I know I'm banging my head against a brick wall here. |
Probably. _________________ Never let the facts get in the way of a good theory. |
|
Back to top |
|
 |
|