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
CVP
VXML
S
ERVER
AND
C
ISCO
U
NIFIED
C
ALL
S
TUDIO
65
are needed, the thread pool grows until it reaches the maximum number of threads allowed. At
that point the queue would grow until threads become available. Threads that complete their
work and cannot find new logger events to handle because the queue is empty will be garbage
collected after a certain amount of time being idle (this is governed by the
LoggerThreadKeepAliveTime option).
that point the queue would grow until threads become available. Threads that complete their
work and cannot find new logger events to handle because the queue is empty will be garbage
collected after a certain amount of time being idle (this is governed by the
LoggerThreadKeepAliveTime option).
Under typical operation, the logger event queue size should not be a large number (one might see
it set to 0 to 10 most of the time). There could be spikes where the queue grows quickly but with
plenty of available threads to handle the events, the queue size should shrink rapidly. The
administrator should take note if the queue size shows a high number, though should be very
wary if this number seems to grow over time (minutes, not seconds). A growing queue size is an
indication that either the load on the system is too high for the thread pool to handle (which is
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.
it set to 0 to 10 most of the time). There could be spikes where the queue grows quickly but with
plenty of available threads to handle the events, the queue size should shrink rapidly. The
administrator should take note if the queue size shows a high number, though should be very
wary if this number seems to grow over time (minutes, not seconds). A growing queue size is an
indication that either the load on the system is too high for the thread pool to handle (which is
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.
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
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