Cisco Cisco Customer Voice Portal 8.0(1) User Guide

Page of 156
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). 
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 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 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. 
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. 
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