The application server log is not resident within ExtraView. The administrator normally accesses this log from the file system of the server. As an alternative, the administrator may view the log from the System Log feature. Directly accessing the log from the file system allows the log to be viewed with an editor. Viewing the application server log from the System log screen only allows the entire log to be viewed.
The path to the log file is specified within the Configuration.properties file for ExtraView. This file is typically, and by default, stored within the ExtraView WEB-INF directory. The path is defined within the within the entry named LOG_FILE_PATH_NAME. For example, in an Apache Tomcat installation of ExtraView with a home directory of /evj, the path to the log file may be similar to /evj/tomcat/webapps/golden411/WEB-INF/logs.
A typical section of the log file in plain text may look like this:
The format of the file is:
timestamp, log entry type, servlet name, session ID, thread #, Entering / Leaving, class and method entered, service count, service count value, total memory available, total memory available value, [free memory available, free memory available value, cache count, cache count value, time, time value], user ID, user ID value, network ID, network ID value
| Parameter | Explanation |
| timestamp | The date and time of the entry |
| log entry type | Normal entries will be shown as INFO. You may also see entries such as ERROR and WARNING |
| Servlet name | Should always be ExtraView |
| session ID | A unique identifier for the session |
| thread # | The thread number that this task is using for execution |
| Entering / Leaving | Shows whether the task is beginning or ending |
| class and method entered | This is the class path and the method within the class that is being executed |
| Service count sc |
The number of processes waiting for service at the instant this request is received. The lower this number, the higher the performance of the system. For short periods of time, this number may exceed 5, but this indicates that users are waiting upon machine resources to execute their tasks. Setting up multiple application servers that each take some of the load is a good solution if this number is consistently high |
| total memory available tmem |
The total memory allocated to this application server. Usually set by the administrator within the start up script for the application server |
| free memory available fmem |
The amount of unused memory. If this drops to a very low number, out of memory errors may occur. If this happens, allocate more total memory to this application server |
| cache count cc |
The total number of user sessions in cache at the time this request is executed. |
| time | The time, in milliseconds, that the request took to execute |
| “morgue” count mc |
The number of sessions currently in the “morgue”. ExtraView allocates sessions to each user to perform virtually every task such as add or update issues, or to run reports. The server stores information about these sessions and retains the information for as long as is needed. Given browser windows may be closed unexpectedly by users, or may be left open for an indeterminate amount of time, the session information is held on the server until the user signs off or their session expires. So that the sign off does not take excessive time, the sessions are not killed at that time, but are flagged as being in the “morgue”. The ExtraView background task named session monitor comes along at a later time and permanently removes the sessions in the morgue, thus killing them permanently. |
| user ID uid |
The user ID of the person who made the request |
| network ID nid |
The network ID and node name within an application server cluster that made the request |
Errors in the log are generated by ExtraView when it encounters an unexpected event or a programming error. Not all errors are fatal; indeed, it is possible to see an error in the log that has absolutely no consequences to the user of ExtraView who caused the error. However, ExtraView endeavors to minimize all programming errors and exceptions in the log. An exception in the log may look like the following error. This error occurred due to a programming error in a pre-release copy of ExtraView.
When you encounter an error condition in ExtraView, the ExtraView support team may ask you to examine the application server log, and to send this to them. We can determine from an error entry where it occurred, and typically use this information to debug and correct programming errors.
Operational problems may occur for a variety of reasons, from a programming bug in ExtraView, to a database problem, to a network problem, to a hardware problem. The list of potential problem areas with Internet technology is vast. Your best friend in debugging problems is the application server log, although other logs and monitoring tools may be useful, even essential, in pinning down the source of a problem.
Significant problems can be understood by correctly interpreting the log.
As part of debugging problems you may want to change Configuration.properties values such as DEBUG_LEVEL and PSP_LOG. There is a URL that allows you to make an API call to ExtraView to change the values of the parameters in the CONFIGURATION.PROPERTIES file, without needing to restart the application server. This is of the form:
user_id=username
&password=password
&statevar= SET_CONFIG_VALUE
&name=parameter_name
&value=YES
An example may be:
http://www.myserver.com/evj/ExtraView/ev_api.action?user_id=
bsmith&password=bill&statevar=SET_CONFIG_VALUE&name=PSP_LOG&
value=YES
