Log4j1 logging

Logs help detect issues and can be implemented in different levels.

Logs are important because they provide information to help you detect:

Application problems - for example, application errors during development
Order processing exceptions - for example, the inventory levels of an item are low and is causing orders to backorder

Logging level

The Sterling™ Order Management System Software's implementation of logging provides the following four application logging levels:

ERRORDTL
ERROR
WARN
INFO

and the following four diagnostic logging levels:

TIMER
SQLDEBUG
DEBUG
VERBOSE

You can turn on all or a combination of some of these levels. You can also designate different log destinations.

For production, you should enable either the INFO or WARN logging level. The application logging levels are cumulative. If you enable INFO, you get all four levels from INFO to ERRORDTL. If you enable WARN, you get three levels from WARN to ERRORDTL.

When needed, you can enable diagnostic logging levels for short periods of time in production. The DEBUG and VERBOSE consume large amount of computing resource and generate large amount of log entries. Enabling VERBOSE logging also enables all diagnostic logging levels from VERBOSE to TIMER as well as all application logging from INFO to ERRORDTL. VERBOSE logs prints out lots of information including the input, intermediate and resulting XMLs, debug information, and so forth.

The TIMER logging level produces a one-line trace entry to record when certain processing sections are entered and exited. This diagnostic logging level is useful for identifying areas for tuning.

The SQLDEBUG diagnostic logging level produces log entries for each SQL statement processed. In addition, SQLDEBUG also enables the TIMER logging level. This logging level is useful if you suspect that there are slow SQL statements.

You can control the log4j1 logging levels by using any one of the following methods:

log4jconfig.xml file.
System Management Console or modifyTraces API call.

The logging level defined in the log4jconfig.xml is restrictive. Therefore, you can define the maximum logging levels allowed for a particular class using the log4jconfig.xml.

You can also set the logging level criteria either through the System Management Console or by calling the modifyTraces API.

If you do not define a logging level criteria through the System Management Console, the logging level is set to 'INFO' or the value defined in the log4jconfig.xml is considered. However, the system will consider the lowest value.

Log destinations

By default, the log4jconfig.xml.sample file defines a ROLLINGFILE_APPENDER with a hard coded destination of /application_path/log/sci.log. If you were to start multiple JVMs (e.g., multiple agents and/or application servers), they all write to the same file. In some cases, the log messages from multiple JVMs could be interleaved.

To avoid this, you can use a parameter to define a separate log file for each JVM. This can be accomplished as follows:

In the log4jconfig.xml, set the ROLLINGFILE_APPENDER as follows:


   <appender name="ROLLINGFILE_APPENDER" 
class="org.apache.log4j.RollingFileAppender">
   <param name="MaxFileSize" value="2048KB" />
   <param name="MaxBackupIndex" value="2" />
   <param name="File" value="${LOGFILE}" />
   <layout class="org.apache.log4j.PatternLayout">
    <param name="ConversionPattern" value="%d:%-7p:%t: %-60m: %-25c{1}%n"/>
   </layout>
   </appender>

Note: For Windows, format the example appropriately.

Pass in the LOGFILE parameter when starting up the JVM. In the following example, the log file has the agent or application server name followed by the node name and a date and time:
```
   AGENT_LOGFILE=${LOG_DIR}/${AGENT_NAME}_{$HOSTNAME}-'date +%Y%m%d%-H%M%S`.log
   java -DLOGFILE=${AGENT_LOGFILE} \
   com.yantra.integration.adapter.IntegrationAdapter
```
Note: For Windows, format the example appropriately.