Cisco Cisco Unified Customer Voice Portal 10.5(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)
71
Note that an instance variable in the logger class will allow it to maintain information that spans
calls. Global logger instances are created when VXML Server initializes and are maintained for
the lifetime of the system and hence the logger class can maintain information that lasts the
lifetime of the system. It will handle any global events that occur.
calls. Global logger instances are created when VXML Server initializes and are maintained for
the lifetime of the system and hence the logger class can maintain information that lasts the
lifetime of the system. It will handle any global events that occur.
A logger is expected to “register” the events it wishes to act on. This is done on logger
initialization. When VXML Server loads, it initializes all the global loggers and the loggers
referenced for an application and records which events each will act on. When a situation occurs
that would constitute an event, VXML 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 logger instances. This registration
mechanism allows VXML 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 VXML Server loads, it initializes all the global loggers and the loggers
referenced for an application and records which events each will act on. When a situation occurs
that would constitute an event, VXML 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 logger instances. This registration
mechanism allows VXML 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 VXML 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.
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 holds up the thread in which it is running. A thread pooling mechanism exists to efficiently
manage thread use. To avoid creating too many threads when under load, the maximum number
of allowable threads in the pool 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 holds up the thread in which it is running. A thread pooling mechanism exists to efficiently
manage thread use. To avoid creating too many threads when under load, the maximum number
of allowable threads in the pool can be configured in the global configuration file named
global_config.xml
found in the
conf
directory of VXML Server by editing the contents of the
<maximum_thread_pool_size>
tag. For a thread to be reused after it is done with the current
task, the <
keep_alive_time>
tag from the same configuration file can be set
.
When all the
allowable threads in the pool are taken, VXML Server will not process the queue until a thread
becomes available from the pool. 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 pool size 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.
becomes available from the pool. 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 pool size 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.