Cisco Cisco Unified Customer Voice Portal 11.0(1) Release Note
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
66
more likely the smaller the maximum thread pool size is set) or for some reason loggers are
taking longer to do their logging. In the latter case this could be due to a slow database
connection, overloaded disk IO or other reasons. Regardless of the cause, a growing queue is a
warning sign that if the call volume is not reduced, the Java application server is at risk of
encountering memory issues and, in the worst case, running out of memory.
taking longer to do their logging. In the latter case this could be due to a slow database
connection, overloaded disk IO or other reasons. Regardless of the cause, a growing queue is a
warning sign that if the call volume is not reduced, the Java application server is at risk of
encountering memory issues and, in the worst case, running out of memory.
It is for this reason that choosing an appropriate maximum thread pool size is important. While
the temptation to give the maximum number of threads a very high number this can also cause
problems on the system as severe as memory issues. Using too many threads could cause what is
called “thread starvation” where the system does not have enough threads to handle standard
background processes and could exhibit unpredictable inconsistent behavior and could also cause
the Java application server to crash.
the temptation to give the maximum number of threads a very high number this can also cause
problems on the system as severe as memory issues. Using too many threads could cause what is
called “thread starvation” where the system does not have enough threads to handle standard
background processes and could exhibit unpredictable inconsistent behavior and could also cause
the Java application server to crash.
The JMX interface supports the ability to change the maximum and minimum thread pool size at
runtime. The administrator should only do this if they believed the change could avert an issue
listed above. For example, if the system is encountering a temporary spike in activity and the
administrator sees the LoggerEventQueueSize attribute report a growing number, then they can
increase the maximum thread pool size to potentially allow for a more rapid handling of the
queued events. Once the queue shrinks to a manageable number the maximum thread pool size
can then be changed back to its original value.
runtime. The administrator should only do this if they believed the change could avert an issue
listed above. For example, if the system is encountering a temporary spike in activity and the
administrator sees the LoggerEventQueueSize attribute report a growing number, then they can
increase the maximum thread pool size to potentially allow for a more rapid handling of the
queued events. Once the queue shrinks to a manageable number the maximum thread pool size
can then be changed back to its original value.
The maximum number of threads set by default in VXML Server is sufficient to handle a very
heavy load without issues so the administrator is urged to use caution when changing these
values.
heavy load without issues so the administrator is urged to use caution when changing these
values.
Session Invalidation Delay Option
The session invalidation delay option is also an important value that an administrator could be
tuned should they see the need. A brief explanation of what this option does is warranted (for
more details refer to Chapter 6: VXML Server Configuration). When a caller ends the call by
either hanging up, going to another application, or the application hangs up on the caller, VXML
Server must perform some final clean up of the call session. This is primarily for processing
logging events that occurred when the call ended. Additionally, application developers can
configure their applications to execute code at the end of a call to perform their own clean up
operations. In sophisticated applications this could involve closing database connections or
generating call detail records. These end of call operations can take a non-trivial amount of time
and may require access to information about the call session, such as element or session data. As
a result, VXML Server waits for a preset period of time after a call ends before it invalidates the
session, allowing all activities requiring additional time to complete. This period of time is
governed by the SessionInvalidationDelay attribute and is measured in seconds.
tuned should they see the need. A brief explanation of what this option does is warranted (for
more details refer to Chapter 6: VXML Server Configuration). When a caller ends the call by
either hanging up, going to another application, or the application hangs up on the caller, VXML
Server must perform some final clean up of the call session. This is primarily for processing
logging events that occurred when the call ended. Additionally, application developers can
configure their applications to execute code at the end of a call to perform their own clean up
operations. In sophisticated applications this could involve closing database connections or
generating call detail records. These end of call operations can take a non-trivial amount of time
and may require access to information about the call session, such as element or session data. As
a result, VXML Server waits for a preset period of time after a call ends before it invalidates the
session, allowing all activities requiring additional time to complete. This period of time is
governed by the SessionInvalidationDelay attribute and is measured in seconds.
It is important to understand the consequences of changing this value. If too low a time is given
then there could be situations where the system under load cannot handle the end of call tasks in
the given time and the global error log may see many errors containing the Java exception
then there could be situations where the system under load cannot handle the end of call tasks in
the given time and the global error log may see many errors containing the Java exception
IllegalStateException
which occurs when attempting to access data from an invalidated call