Cisco Cisco Unified Customer Voice Portal 11.0(1) User Guide
C
HAPTER
3:
A
DMINISTRATION
U
SER
G
UIDE FOR
C
ISCO
U
NIFIED
CVP
VXML
S
ERVER
AND
C
ISCO
U
NIFIED
C
ALL
S
TUDIO
64
value is given, it takes affect immediately with no confirmation so it is important to ensure that
the value entered is correct. There is some simple validation that takes place by VXML Server
and if the value entered is inappropriate (such as entering -1 where a positive integer is required),
the change will not take place and the original value will remain unchanged. The administrator
will know that their entry was accepted if the value does not revert back.
the value entered is correct. There is some simple validation that takes place by VXML Server
and if the value entered is inappropriate (such as entering -1 where a positive integer is required),
the change will not take place and the original value will remain unchanged. The administrator
will know that their entry was accepted if the value does not revert back.
It is very important to note that any changes made to these attributes are not persisted. The
changes affect VXML Server in memory and do not affect the XML files that hold these values.
As a result, should the Java application server or the VXML Server web application be restarted
or for application-specific attributes the application is updated, the attributes will revert back to
the values specified in their respective XML files.
changes affect VXML Server in memory and do not affect the XML files that hold these values.
As a result, should the Java application server or the VXML Server web application be restarted
or for application-specific attributes the application is updated, the attributes will revert back to
the values specified in their respective XML files.
VXML Server Configuration Options
To view the VXML Server configuration options using the JMX interface, navigate to the
Global/Configuration
MBean. There are five attributes listed. The first, named
“LoggerEventQueueSize”, will show the current size of the queue that holds logger events
waiting to be sent to loggers and is not editable. The next three are related in that they control
aspects of the logger thread pool. The final configuration option deals with a period of time
VXML Server waits after a caller ends their call before the call session is invalidated. All of
these options affect the performance of the system and are defined fully in Chapter 6: VXML
Server Configuration. Use the following table to reference the JMX attribute name with the
waiting to be sent to loggers and is not editable. The next three are related in that they control
aspects of the logger thread pool. The final configuration option deals with a period of time
VXML Server waits after a caller ends their call before the call session is invalidated. All of
these options affect the performance of the system and are defined fully in Chapter 6: VXML
Server Configuration. Use the following table to reference the JMX attribute name with the
global_config.xml
tag name.
JMX Attribute Name
Tag Name
LoggerMaximumThreadPoolSize
<maximum_thread_pool_size>
in the
<logger>
tag.
LoggerMinimumThreadPoolSize
<minimum_thread_pool_size>
in the
<logger>
tag.
LoggerThreadKeepAliveTime
<keep_alive_time>
in the
<logger>
tag.
SessionInvalidationDelay
<session_invalidation_delay>
Table 3-1
Tuning Logger Options
The most important indication of whether VXML Server is encountering issues with loggers is
the “LoggerEventQueueSize” attribute. A brief explanation of how VXML Server handles
loggers is warranted (for more details refer to Chapter 5: VXML Server Logging). In order to
prevent logging from holding up calls, all logging is done in separate threads. The threads are
managed within a thread pool, which has a maximum and minimum value. When VXML Server
starts up, the thread pool allocates the minimum number of threads. As calls begin to be handled,
they generate logger events, which are put into a queue of events. The activation of a logger
event also prompts VXML Server to request a thread from the pool and in that thread have the
appropriate logger handle the top most event in the queue. The length of time this thread handles
the event depends on the logger, but the event is typically handled in a very short period of time,
measured in milliseconds. However as call volume on the system increases, more threads are
used simultaneously to handle the increase in logger events added to the queue. As more threads
the “LoggerEventQueueSize” attribute. A brief explanation of how VXML Server handles
loggers is warranted (for more details refer to Chapter 5: VXML Server Logging). In order to
prevent logging from holding up calls, all logging is done in separate threads. The threads are
managed within a thread pool, which has a maximum and minimum value. When VXML Server
starts up, the thread pool allocates the minimum number of threads. As calls begin to be handled,
they generate logger events, which are put into a queue of events. The activation of a logger
event also prompts VXML Server to request a thread from the pool and in that thread have the
appropriate logger handle the top most event in the queue. The length of time this thread handles
the event depends on the logger, but the event is typically handled in a very short period of time,
measured in milliseconds. However as call volume on the system increases, more threads are
used simultaneously to handle the increase in logger events added to the queue. As more threads