Cisco Cisco Customer Voice Portal Downloads User Guide
C
HAPTER
5:
V
OICE
XML
S
ERVER
L
OGGING
V
OICE
XML
S
ERVER
U
SER
G
UIDE
FOR
C
ISCO
U
NIFIED
C
USTOMER
V
OICE
P
ORTAL
R
ELEASE
4.0(1)
78
granularity set to
seconds
, just the hours, minutes and seconds will be displayed. For a
granularity set to
milliseconds
, all components will be displayed.
o
minimal
. This is a minimal time value that omits the date and is in the form
“HH:MM[:SS][.MMM]” where the hour is in 24-hour time and the last three digits are
the milliseconds. The seconds and milliseconds are displayed with brackets to indicate
that their appearance are based on the
the milliseconds. The seconds and milliseconds are displayed with brackets to indicate
that their appearance are based on the
date_granularity
attribute. For a
date_granularity
attribute set to
minutes
, just the hours and minutes will be
displayed. For a granularity set to
seconds
, just the hours, minutes and seconds will be
displayed. For a granularity set to
milliseconds
, all components will be displayed.
o
number
. This displays a large integer number representing the full date and time as an
elapsed time since January 1, 1970, 00:00:00 GMT. For a
date_granularity
attribute
set to
minutes
, the number will be 8 digits in length (representing the number of minutes
elapsed since that date). For a granularity set to
seconds
, the number will be 10 digits in
length (representing the number of seconds elapsed since that date). For a granularity set
to
to
milliseconds
, the number will be 13 digits in length (representing the number of
milliseconds elapsed since that date).
print_stack_traces
. This required attribute is set to either
true
or
false
and determines
whether the error log will contain Java stack traces. Stack traces are very useful to a
developer in tracking down the cause of a Java error so it is recommended to keep this option
on.
developer in tracking down the cause of a Java error so it is recommended to keep this option
on.
Error Logger Configuration: File Purging
The Error Logger can be configured to automatically delete files that conform to certain criteria.
Properly configured, this will allow an administrator to avoid having the system’s hard drive fill
up with logs, thereby preventing new calls from being logged. A few notes about file purging
that must be understood:
Properly configured, this will allow an administrator to avoid having the system’s hard drive fill
up with logs, thereby preventing new calls from being logged. A few notes about file purging
that must be understood:
A few notes about file purging that must be understood:
Since loggers are activated only when events occur in a call, the file purging activity will
only take place when an error event occurs. As a result, a system that encounters no errors
will not automatically delete files until a new error occurs.
will not automatically delete files until a new error occurs.
When the Error Logger starts up for the first time, it will apply the purging strategy on any
files that exist in the logger directory. Therefore, if an application server is shut down with
files in the logger directory and then restarted a long time later, these files could be deleted
when the application server starts up and the logger initializes. This applies to any file
appearing in the logger directory, not just error logs.
files in the logger directory and then restarted a long time later, these files could be deleted
when the application server starts up and the logger initializes. This applies to any file
appearing in the logger directory, not just error logs.
Unlike the Activity Logger, the Error Logger applies its purging strategy to any files found in
its logger directory, including non-error log files. So should other files be added to the logger