JAVA LOGGING for JAVA APPLICATION PERFORMANCE

JAVA LOGGING for JAVA APPLICATION PERFORMANCE in a Web Logic Server
Java logging or logging in java is as much an art as science. knowing write tools and API
for java logging is definitely science part but choosing format of java logs , format of messages,what to log in java ,
which logging level to use for which kind of messages are purely an experienced based things and sort of art which
you learn by applying logging in java. Since its proven fact that java logging severely affects performance and I
have seen latency of online stocktrading application goes multiple times if they run in DEBUG mode than in
WARN or higher level mode. Since latency and speed is major concern for any electronic trading systemor high
volume low latency stocktrading system, it becomes absolutely necessary to understand and learn java logging in
great details and best practices and tips available on logging in java. This is not jus t for finance and investment
banking domain but also to any java server or client application which requires speed and java logging at same
time. Most J2EE applications use well defined interfaces that are part of the J2EE specification. These interfaces
include Servlets, JSPs (Java Server Pages), JDBC (Java Database Connectivity) drivers and EJBs (Enterprise
JavaBeans). Usually, the byte code instrumentation of such interfaces brings mechanized recognition of the response
time contributions pertaining to the usage of relational databases (RDBMS), enterprise beans,and otheruser
interfaces. J2EE applications normally spend significant amounts of time performing operations outside the scope of
common interfaces such as using third party packages,communicating with legacy applications and executing the
business logic that is unique to the application.
1.0 Why we need logging in Java
Why we need java logging? This is a very basic question and everybody argue that if we have Java
System.out.println () for printing messages then why we use logging. In java application printing SOP in console
every time is not a good practice. Several technology like JSP, Servlet and other java web based frame work not
using console they work with browser Component. In production environment, when we deploy any java application
then according to business perspective we should know that what is response of our application for particular request
,also during that request we should know that what is health and status of server including Admin server and
managed server with cluster environment. If you are writing a java application server then only way to know what
your server is doing is by seeing log file of your server. suppose you don't write anything in yourjava log file then
nobody knows what your severis doing, it becomes increasingly important if your application is connected to
upstreamand downstreamlike in many stock trading systems or electronic trading systemand get input from
upstream, transforms and normalize it and send down to downstream. In case of any issue without java logs you
won't be able to figure out what went wrong. If we solve any issues related to web base application it’s important to
check server logs. Without seeing logs of server we are unable to find bug or track any issue related to our java
application. Addressing the performance issues of these complex J2EE applications may consume an increasing
amount of IT staff time. As the complexity and the scope of enterprise operations increas e, so does the hazards of
failure. Various studies showthat serious application issues occurin 15% of enterprises every day and around 53%
of enterprises every week. According to a recent Forrester Research survey,many new applications are actually the
revamping or front-ending of old applications using J2EE application servers,for instance. The introduction of these
technologies and the trends toward using service oriented architecture and web services increase the complexity of
applications. Nearly 85% of enterprises with revenue of more than $1 billion reported incidents of significant
application performance issues.Survey respondents identified architecture and deployment as the primary causes of
these issues.Based on this survey,it seems that no matter how much one tunes the hardware and environment,
application issues will persist.

2.0 What are different logging level in Java
Java logging basically depend on tools and java.util.logging API.
1) Following logging level is based on log4jlogging level.
DEBUG is the lowest restricted java logging level and we should write everything we need to debug an application,
this java logging mode should only be used on Development and Testing environment and must not be used in
production environment.
INFO is more restricted than DEBUG java logging level and we should log messages which are informative
purpose like Server has been started,Incoming messages,outgoing messages etc in INFO level logging in Java.
WARN is more restricted than INFO java logging level and used to log warning sort of messages e.g. Connection
lost between client and server. Database connection lost, Socket reaching to its limit. These messages and java
logging level are almost important because you can setup alert on these logging messages in Java and let your
support team monitor health of yourjava application and react on this warning messages.In Summary WARN level
is used to log warning message for logging in Java.
ERROR is the more restricted java logging level than WARN and used to log Errors and Exception, you can also
setup alert on this java logging level and alert monitoring team to react on this messages. ERROR is serious for
logging in Java and you should always print it.
FATAL java logging level designates very severe error events that will presumably lead the application to abort.
After this mostly your application crashes and stopped.
OFF java logging level has the highest possible rank and is intended to turn off logging in Java.
Above level are different than java.util.logging API.
2) Java.util.logging API which provides some more logging level like SEVERE, FINER, FINEST, FATAL etc. as
name suggest based upon criticality of your logging message you can choose any of this level for logging in Java. In
this article we a discuss serverlog and its related to web logic server which is a part of java.util.logging API. First of
we discuss here how logging effects on java application.
3.0 How logging in Java affects performance
Java logging severely affects performance of your application. It’s quite common sense that more you log, more you
perform file IO which slows down your application. In production environment basically in case of web logic server
we have .out log file whose size increases while we access anything or perform any operation on application. If this
size increase’s in GB or up to threshold then admin server goes down automatically and we are unable to access our
deployed application. Anotherissue with this .out log file it slows the response of application which effects in HTTP
response.That's why choosing correct java logging level for every single message is quite important. Since having
no java logging is not a choice you have to have logging in java application, what you can control is logging level
and logging messages on that level. In case of logging tool either use WARN ERROR or FINER, FINEST java
logging level in production environment. Never use DEBUG level logging in java in production.

4.0 Understanding WebLogic Logging Services
WebLogic logging services provide facilities for writing, viewing, filtering, and listening for log messages.These
log messages are generated by WebLogic Server instances,subsystems,and J2EE applications that run on
WebLogic Server or in client JVMs.
4.1 Components and Environment
There are two basic components in any logging system: a component that produces log messages and another
component to distribute (publish) messages.WebLogic Server subsystems use a message catalog feature to
produce messages and the Java Logging APIs to distribute them, by default. Developers can also use
message catalogs for applications they develop.
The message catalog framework provides a set of utilities and APIs that your application can use to send its
own set of messages to the WebLogic server log. The framework is ideal for applications that need to
localize the language in their log messages,but even for those applications that do not need to localize, it
provides a rich, flexible set of tools for communicating status and output.
4.2 WebLogic Server Logging Process
Fig 4.2 illustrates the following process:
1. The client, in this case, a WebLogic Server subsystemor J2EE application, invokes a method on one of
the generated Catalog Loggers or the Commons Logging implementation for WebLogic Server.
a. When WebLogic Server message catalogs and the NonCatalogLogger generate
messages,they distribute their messages to the server Logger object.

b. The Jakarta Commons Logging APIs define a factory API to get a Logger reference
which dispatches log requests to the server Logger object. The server Logger object can be an
instance of java.util.logging.
2. The server Logger object publishes the messages to any message handler that has
subscribed to the Logger.
For example, the Stdout Handler prints a formatted message to standard out and the File Handler writes
formatted output to the server log file. The Domain Log Broadcaster sends log messages to the domain
log, which resides on the Administration Server, and the JMX Log Broadcaster sends log messages to
JMX listeners on remote clients.
5.0 Server Log Files and Domain Log Files
Each WebLogic Server instance writes all messages from its subsystems and applications to a server log file
that is located on the local host computer. By default, the server log file is located in the logs directory below
the server instance root directory; for
example, DOMAIN_NAMEserversSERVER_NAMElogsSERVER_NAME.log, where DOMAIN_NAME is
the name of the directory in which you located the domain and SERVER_NAME is the name of the server.In
addition to writing messages to the server log file, each server instance forwards a subset ofits messages to a
domain-wide log file. By default, servers forward only messages of severity level NOTICE or higher. While
you can modify the set of messages that are forwarded, servers can never forward messages of
the DEBUG severity level. The domain log file provides a central location from which to view the overall
status ofthe domain. The domain log resides in the Administration Server logs directory. The default name
and location for the domain log file
is DOMAIN_NAMEserversADMIN_SERVER_NAMElogsDOMAIN_NAME.log,
where DOMAIN_NAME is the name of the directory in which you located the domain
and ADMIN_SERVER_NAME is the name of the Administration Server. The timestamp for a record in the
domain log is the timestamp of the server where the message originated. Log records in the domain log are
not written in the order of their timestamps; the messages are written as soon as they arrive. It may happen
that a Managed Server remains out of contact with the Administration Server for some period of time. In that
case, the messages are buffered locally and sent to the Administration Server once the servers are
reconnected.For any given WebLogic Server instance, you can override the default filter and create a log
filter that causes a different set of messages to be written to the domain log file. If the Administration Server
is unavailable, Managed Servers continue to write messages to their local server log files. However, by
default, when the servers are reconnected,not all the messages written during the disconnected period are
forwarded to the domain log file. A Managed Server keeps a specified number of messages in a buffer so
they can be forwarded to the Administration Server when the servers are reconnected. The number of
messages kept in the buffer is configured by the DomainLogBroadcasterBufferSizeattribute on the
LogMBean. The default value of this attribute in development mode is 1. With that default value, only the
last logged message is forwarded to the Administration Server once it is reconnected.For example, if the
Administration Server is unavailable for two hours and then is restored,the domain log will not contain any
messages that were generated during the two hours.If you have configured a value greater than 1, that
number of messages will be forwarded to the domain log when the Managed Server is reconnected to the
Administration Server. The default value of the DomainLogBroadcasterBufferSize attribute in production
mode is 10.

5.1 Server Log
The server log records information about events such as the startup and shutdown ofservers, the deployment
of new applications, or the failure of one or more subsystems.The messages include information about the
time and date of the event as well as the ID of the userwho initiated the event.
You can view and sort these server log messages to detect problems, track down the source of a fault, and
track systemperformance. You can also create client applications that listen for these messages and respond
automatically. For example, you can create an application that listens for messages indicating a failed
subsystemand sends E-mail to a systemadministrator.
The server log file is located on the computer that hosts the serverinstance. Each server instance has its own
server log file. By default, the server log file is located in the logs directory below the server instance root
directory; for example, DOMAIN_NAMEserversSERVER_NAMElogsSERVER_NAME.log,
where DOMAIN_NAME is the name of the directory in which you located the domain
and SERVER_NAME is the name of the server. To view messages in the server log file, you can log on the
WebLogic Server host computer and use a standard text editor, or you can log on to any computer and use
the log file viewer in the Administration Console.
NOTE: BEA Systems recommends that you do not modify log files by editing them manually. Modifying
a file changes the timestamp and can confuse log file rotation. In addition, editing a file might lock
it and prevent updates from WebLogic Server and interfere with the Accessorfunctionality.
Note:
In addition to writing messages to a log file, each server instance prints a subset ofits messages to standard
out. Usually, standard out is the shell (command prompt) in which you are running the server instance.
However, some operating systems enable you to redirect standard out to some otherlocation. By default, a
server instance prints only messages of a NOTICE severity level or higher to standard out.If you use the
Node Manager to start a Managed Server, the messages that would otherwise be output
to stdout orstderr .when starting a Managed Server, are instead displayed in the Administration Console and
written to a single log file for that server instance, SERVER_NAME.out. The server instance's output log is
located in the same logs directory, below the server instance root directory, along with the WebLogic
Server SERVER_NAME.log file; for
example, DOMAIN_NAMEserversSERVER_NAMElogsSERVER_NAME.out,whereDOMAIN_NAME is
the name of the directory in which you located the domain and SERVER_NAME is the name of the server.
The Node Manager writes its own startup and status messages to a single log
file, NM_HOME/nodemanager.log, where NM_HOME designates the Node Manager installation directory,
by default, WL_HOME/common/nodemanager.
5.2 Subsystem Logs
The server log messages and log file communicate events and conditions that affect the operation of the
server or the application. Some subsystems maintain additional log files to provide an audit of the
subsystem's interactions under normal operating conditions.The following list describes each of the
additional log files:
 The HTTP subsystemkeeps a log of all HTTP transactions in a text file. The default location and rotation
policy for HTTP access logs is the same as the server log. You can set the attributes that define the
behavior of HTTP access logs for each server or for each virtual host that you define. Each server has a
transaction log which stores information about committed transactions coordinated by the server that may

not have been completed. WebLogic Server uses the transaction log when recovering from systemcrashes
or network failures. You cannot directly view the transaction log—the file is in a binary format.
The Transaction Manager uses the default persistent store to store transaction log files. Using the
Administration Console, you can change where the default store is located The WebLogic Auditing
provider records information from a number of security requests,which are determined internally by the
WebLogic Security Framework. The WebLogic Auditing provider also records the event data associated
with these security requests,and the outcome of the requests.Configuring an Auditing provider is
optional. The default security realm (myrealm) does not have an Auditing provider configured. All
auditing information recorded by the WebLogic Auditing provider is saved
in WL_HOMEDOMAIN_NAMEserversSERVER_NAMElogsDefaultAuditRecorder.log. Although an
Auditing provider is configured per security realm, each server writes auditing data to its own log file in
the server directory.
 The JDBC subsystemrecords various events related to JDBC connections,including registering JDBC
drivers and SQL exceptions. The events related to JDBC are now written to the server log, such as when
connections are created or refreshed or when configuration changes are made to JDBC objects. JMS
logging is enabled by default when you create a JMS server, however, you must specifically enable it on
message destinations in the JMS modules targeted to this JMS server (or on the JMS template used by
destinations).
JMS server log files contain information on basic message life cycle events,such as message production,
consumption, and removal. When a JMS destination hosting the subject message is configured with
message logging enabled, then each of the basic message life cycle events will generate a message log
event in the JMS message log file.
The message log is located in the logs directory, below the server instance root
directory,DOMAIN_NAMEserversSERVER_NAMElogsjmsServersSERVER_NAMEJMSServerjms.m
essages.log,where DOMAIN_NAME is the name of the directory in which you located the domain
and SERVER_NAME is the name of the server.
After you create a JMS server, you can change the default name of its log file, as well as configure
criteria for moving (rotating) old log messages to a separate file.
6.0 Configure java.util.logging loggerlevels
To configure java.util.logging logger levels:
1. Go to Administration Console, click Lock & Edit .
2. In the left pane of the Console, select Environment > Servers.
3. In the Servers table, select the server instance you want to configure.
4. Select the Logging > General page and expand the Advanced section.
5. In the Platform Logger Levels field, you can specify pairs of logger names and logger levels.
Note: You can specify multiple pairs of logger names and logger levels by entering each pair on a separate
line.
6. Click Save.
7. To activate these changes,in the Change Center of the Administration Console, click Activate Changes.
Not all changes take effect immediately—some require a restart .

7.0 Viewing WebLogic Server Logs
The WebLogic Server Administration Console provides a log viewer for all the log files in a domain.
The log viewer can find and display the messages based on any of the following message attributes: date,
It can also display messages as they subsystem,severity, machine, server, thread, userID, transaction
ID, context ID, timestamp, message ID, or message. are logged or search for past log messages
8.0 Tips and conclusion
In a web logic serve after checking the server and subsystemlog we are able to debug some production issues.
But it is not case in every scenario after checking log we are able to solve issues from production. It totally depend
on what you logged in server log and which logging API we used during development of an application in web
logic. During development and deployment which configuration we made between application and server plays
important role in a logging, also which log level we used help us to trace some issue regarding application and
server status in a server log.
1) Never log sensitive information
2) Always log decision making statements.
3) Consistency: Consistency is key knot just in logging but also in coding. Doesn’t matter which format you follow
if you are consistent with that format than only it adds a value but spend some time to decide your logging format so
that it can capture all useful information.
4) Log all important information which is necessary to debug or troubleshoot a problem if it happens.

JAVA LOGGING for JAVA APPLICATION PERFORMANCE

JAVA LOGGING for JAVA APPLICATION PERFORMANCE

More Related Content

What's hot

Viewers also liked

Similar to JAVA LOGGING for JAVA APPLICATION PERFORMANCE

JAVA LOGGING for JAVA APPLICATION PERFORMANCE