Cisco Cisco Unified Customer Voice Portal 10.0(1) ユーザーガイド
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
66
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 Call Services is sufficient to handle a very
heavy load so the administrator is urged to use caution when changing these values.
heavy load 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. A brief explanation of what this option does is warranted (for more details refer to
Chapter 6: Call Services Configuration). When a caller ends the call by either hanging up, going
to another application, or the application hangs up on the caller, Call Services 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
tuned. A brief explanation of what this option does is warranted (for more details refer to
Chapter 6: Call Services Configuration). When a caller ends the call by either hanging up, going
to another application, or the application hangs up on the caller, Call Services 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