Cisco Cisco Customer Voice Portal 8.0(1) Developer's Guide
C
HAPTER
13:
L
OGGERS
P
ROGRAMMING
G
UIDE FOR
C
ISCO
U
NIFIED
CVP
VXML
S
ERVER
AND
C
ISCO
U
NIFIED
C
ALL
S
TUDIO
R
ELEASE
4.1(1)
72
There are times when the true asynchronous nature of the logging design works against the
developer. The tasks done by a logger can take a variable amount of time to complete so there is
no guarantee when a call event will be handled. This is by design, and for a logger that simply
records events that are then sorted by timestamp later, this is not a problem. A logger that
requires more context, though, could encounter issues. For example, if a logger needed to note
when a call was received so that an event that occurred later on in the call could be handled
correctly, problems could be encountered because there would be no guarantee that the events
would be handled in the same order they occurred within the call. To remedy this situation while
keeping the design unfettered, it is possible to specify that VXML Server pass a logger instance
events in the same order they occurred in a call. With this option on, the logger developer can be
assured that the events for a call would not be handled out of order. In fact, the Activity Logger
included with VXML Server has this requirement. The penalty for this requirement, however, is
a loss of some of the true asynchronous nature of the system as there will now be situations
where events that are ready to be handled must wait for a previous event to be handled by the
logger. If a logger hung while handling one event, the queue would forever contain the events
that occurred after it in the call, and that call session would not be fully logged. This feature,
however, is available to application loggers only, global loggers handle their events as soon as a
thread is allocated from the pool to handle it. This is understandable because global log events
are more holistic in nature and do not track detailed behavior as application loggers do.
developer. The tasks done by a logger can take a variable amount of time to complete so there is
no guarantee when a call event will be handled. This is by design, and for a logger that simply
records events that are then sorted by timestamp later, this is not a problem. A logger that
requires more context, though, could encounter issues. For example, if a logger needed to note
when a call was received so that an event that occurred later on in the call could be handled
correctly, problems could be encountered because there would be no guarantee that the events
would be handled in the same order they occurred within the call. To remedy this situation while
keeping the design unfettered, it is possible to specify that VXML Server pass a logger instance
events in the same order they occurred in a call. With this option on, the logger developer can be
assured that the events for a call would not be handled out of order. In fact, the Activity Logger
included with VXML Server has this requirement. The penalty for this requirement, however, is
a loss of some of the true asynchronous nature of the system as there will now be situations
where events that are ready to be handled must wait for a previous event to be handled by the
logger. If a logger hung while handling one event, the queue would forever contain the events
that occurred after it in the call, and that call session would not be fully logged. This feature,
however, is available to application loggers only, global loggers handle their events as soon as a
thread is allocated from the pool to handle it. This is understandable because global log events
are more holistic in nature and do not track detailed behavior as application loggers do.
Some of the conclusions that can be deduced from the VXML Server logging design can be
summarized in some best practices:
summarized in some best practices:
•
A logger developer need not worry about the time taken by the logger to handle an event as it
will have no bearing on the performance of the call. With that said, the developer must also
be aware of the expected call volume and ensure that the logger not take so long as to use up
the event threads faster than they can be handled.
will have no bearing on the performance of the call. With that said, the developer must also
be aware of the expected call volume and ensure that the logger not take so long as to use up
the event threads faster than they can be handled.
•
Loggers work under a multi-threaded environment and the logger developer must understand
how to code with this in mind. A single logger class can be handling events for many calls
and so it must manage internal and external resources in a synchronized manner to prevent
non-deterministic behavior.
how to code with this in mind. A single logger class can be handling events for many calls
and so it must manage internal and external resources in a synchronized manner to prevent
non-deterministic behavior.
•
When possible, design an application logger so that it does not rely on events within a call
being passed to it in the order in which they occurred in the call. Doing so will maximize
performance due to being able to handle events whenever they occur. Should the logger be
unable to do so, require that the enforce call event order option be turned on for the logger.
being passed to it in the order in which they occurred in the call. Doing so will maximize
performance due to being able to handle events whenever they occur. Should the logger be
unable to do so, require that the enforce call event order option be turned on for the logger.
Logger Design
Similar to configurable elements, a logger is constructed by creating a Java class that extends an
abstract base class,
abstract base class,
GlobalLoggerBase
or
ApplicationLoggerBase,
which in turn extend from
the LoggerBase class. The base classes define abstract methods that must be implemented by the
logger. Loggers have methods for initialization and destruction as well as an execution method to
logger. Loggers have methods for initialization and destruction as well as an execution method to