Cisco Cisco Unified Customer Voice Portal 10.0(1) Guía Del Usuario
C
HAPTER
3:
A
DMINISTRATION
U
SER
G
UIDE FOR
C
ISCO
U
NIFIED
C
ALL
S
ERVICES
,
U
NIVERSAL
E
DITION
AND
U
NIFIED
C
ALL
S
TUDIO
65
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 Call Services 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 Call Services 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 Call Services in memory and do not affect the XML files that hold these values.
As a result, should the Java application server or the Call Services 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 Call Services in memory and do not affect the XML files that hold these values.
As a result, should the Java application server or the Call Services 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.
Call Services Configuration Options
To view the Call Services 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 Call
Services 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: Call Services
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 Call
Services 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: Call Services
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 Call Services is encountering issues with loggers is the
“LoggerEventQueueSize” attribute. A brief explanation of how Call Services handles loggers is
warranted (for more details refer to Chapter 5: Call Services 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 Call Services 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 Call Services 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
“LoggerEventQueueSize” attribute. A brief explanation of how Call Services handles loggers is
warranted (for more details refer to Chapter 5: Call Services 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 Call Services 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 Call Services 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