Cisco Cisco Unified Customer Voice Portal 11.0(1) 开发者指南
C
HAPTER
13:
L
OGGERS
V
OICE
XML
P
ROGRAMMING
G
UIDE
FOR
C
ISCO
U
NIFIED
C
USTOMER
V
OICE
P
ORTAL
R
ELEASE
4.0(1)
67
single instance. Note that an instance variable in the logger class will allow it to maintain
information that spans calls.
information that spans calls.
A logger is expected to “register” the events it wishes to act on. This is done on logger
initialization. When Unified CVP VoiceXML Server loads, it initializes all the loggers
referenced for an application the records which events each will act on. When a situation occurs
that would constitute an event, the VoiceXML Server checks to see if any loggers will act on the
event and if so, will create the event object and pass it to the loggers. This registration
mechanism allows the VoiceXML Server to save the overhead in creating an event if no loggers
will act on it. Additionally, should there be multiple loggers acting on an event, only one event
object is created and passed to all of them.
initialization. When Unified CVP VoiceXML Server loads, it initializes all the loggers
referenced for an application the records which events each will act on. When a situation occurs
that would constitute an event, the VoiceXML Server checks to see if any loggers will act on the
event and if so, will create the event object and pass it to the loggers. This registration
mechanism allows the VoiceXML Server to save the overhead in creating an event if no loggers
will act on it. Additionally, should there be multiple loggers acting on an event, only one event
object is created and passed to all of them.
In order to ensure that no call be held up due to logging activities, the entire Unified CVP
VoiceXML Server logging mechanism is fully multi-threaded. The only logging-related activity
that an HTTP request thread provided by the application server performs is creating an event
object and adding it to a queue. It does not actually handle the logging of that event and once it
has added the event to the queue, it continues with the call. A separate, constantly running
asynchronous process, called the Logger Manager, will process the events in the queue. This
allows the logging process to act independently from the process of handling a call and so will
not directly affect the performance of the system.
VoiceXML Server logging mechanism is fully multi-threaded. The only logging-related activity
that an HTTP request thread provided by the application server performs is creating an event
object and adding it to a queue. It does not actually handle the logging of that event and once it
has added the event to the queue, it continues with the call. A separate, constantly running
asynchronous process, called the Logger Manager, will process the events in the queue. This
allows the logging process to act independently from the process of handling a call and so will
not directly affect the performance of the system.
In order to ensure that no logger be held up due to the activities of another logger (or the same
logger) while handling an event, a second layer of threads are used. While the Logger Manager
handles the queue, when it is time for a logger to be given the event to handle, this is itself done
in a separate thread. The Logger Manager therefore is responsible only for managing the queue
of events and spawning threads for loggers to handle them. This ensures that a logger that takes a
long time to handle an event does not hold up the logging for the same or other applications, it
only hold up the thread in which it is running. To avoid creating too many threads when under
load, the maximum number of allowable threads can be configured in the global configuration
file named
logger) while handling an event, a second layer of threads are used. While the Logger Manager
handles the queue, when it is time for a logger to be given the event to handle, this is itself done
in a separate thread. The Logger Manager therefore is responsible only for managing the queue
of events and spawning threads for loggers to handle them. This ensures that a logger that takes a
long time to handle an event does not hold up the logging for the same or other applications, it
only hold up the thread in which it is running. To avoid creating too many threads when under
load, the maximum number of allowable threads can be configured in the global configuration
file named
global_config.xml
found in the
conf
directory of the VoiceXML Server by editing
the contents of the
<thread_limit>
tag. When all the allowable threads are taken, the
VoiceXML Server will not process the queue until a thread becomes available. Note that one of
the consequences here is that the longer the events remain in the queue, the less “real-time” the
logging will occur. Additionally, if the maximum thread count is made too low to handle a given
call volume, the queue can become very large and could eventually cause issues with memory
and spiking CPU. Typically, though, a logger handles an event in a very short period of time,
allowing a small number of threads to handle the events created by many times that number of
simultaneous callers.
the consequences here is that the longer the events remain in the queue, the less “real-time” the
logging will occur. Additionally, if the maximum thread count is made too low to handle a given
call volume, the queue can become very large and could eventually cause issues with memory
and spiking CPU. Typically, though, a logger handles an event in a very short period of time,
allowing a small number of threads to handle the events created by many times that number of
simultaneous callers.
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
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