It shall be possible to support trouble shooting activities (both on cluster
level as well as per node in a cluster) on a system that is running under
normal load at a customer site. Currently trouble shooting the system is a
The exit level of the requirement is that it shall be possible to enable
logging (for a loglevel selected as appropriate for trouble shooting) on a
system that is running 100 TPS SIP and 100 TPS HTTP per paylode node under a
short period of time (i.e. 10-20 seconds) without downgrading the system
The more general requirement is that trouble shooting on a system that is
running live traffic (normal load) shall be possible
Items that can be considered to meet the requirement is:
- "Clean up" a specific loglevel (or create a new) that can be used for trouble
shooting purposes for a limited amount of time with a limited load.
- Increase the performance of logging by introducing Glassfish v3 logging which
applies to FileandSyslogHandler. V2 logging has a synchronous implementation.
- Have a a separate log level for traffic driven 'errors' and 'warnings'
messages.- Make it possible to activate logging on a fine granular level.
- Support that the logging can be turned on for a specified "short period" of
time or number of requests.
- Have log information accumulated in an internal buffer and only written when
a fault occurs.
- Support that logging is initiated on a specific criteria. (for example the
requesting user or message type)
- Support Tracing Capabilities.
- Include/Support a "support" product such as BTRACE enabling effective trouble