Scenario: Interpreting log file statements to resolve errors

Marco, a system administrator, wants to isolate and resolve an error that occurs when someone tries to save a work order. Marco can troubleshoot the problem by setting the Word Order Tracking root logger to DEBUG and the SQL root logger to INFO.

Replicating the error

In the Work Order Tracking application, Marco creates a work order and associates multiple tasks with the work order. Each task is arranged in sequence. When Marco tries to save the work order, the error BMXAA5395E Task 20 is causing a loop condition by connecting back to task 10 is shown. The work order cannot be saved. If Marco enables the Work Order Tracking application logger and the SQL logger, he can view detailed information to determine the cause of the error.

Enabling loggers

In the Logging application, Marco searches for the WOTRACK root logger and sets the log level to DEBUG. Then, Marco searches for the SQL root logger and the WORKORDER child logger, and sets the log level for both loggers to INFO. Marco associates an appender with each logger.

Creating the log file statements

Marco attempts to save the work order again, but encounters the same error. Because Marco enabled the loggers, a detailed log file statement is produced. The cause of the error can be isolated by interpreting the log file statement.

Interpreting the log file statement

The log file statement shows a path that lists a sequence of successor tasks.

21 May 2012 11:37:03:927 [DEBUG] [MXServer] [] Task Successors

Task 40 is represented in the log file with the identifier T1088.

21 May 2012 11:37:03:929 [DEBUG] [MXServer] [] Task -> T1088  Successors -> []

Task 30 is represented in the log file with the identifier T1087.

21 May 2012 11:37:03:929 [DEBUG] [MXServer] [] Task -> T1087  Successors -> []

Task 20 is represented in the log file with the identifier T1086.

21 May 2012 11:37:03:930 [DEBUG] [MXServer] [] Task -> T1086  Successors -> 
[T1085, T1088]

Task 10 is represented in the log file with the identifier T1085.

21 May 2012 11:37:03:930 [DEBUG] [MXServer] [] Task -> T1085  Successors -> 
[T1086, T1087]

Task 50, represented in the log file statement with the identifier T1089, has successors Tasks 10 (T1085), 20 (T1086) and 30 (T1087).

21 May 2012 11:37:03:931 [DEBUG] [MXServer] [] Task -> T1089  Successors -> 
[T1085, T1086, T1087]

Each path for a sequence of tasks in the Work Order Tracking application is validated. Each path is called a branch. For each branch, the application determines whether any of the tasks in the branch points back to itself somewhere in the branch. This condition is called a loop.

After the list of tasks is created, each branch is validated starting at Task 50 (T1089).

21 May 2012 11:37:03:931 [DEBUG] [MXServer] [] Beginning from a new starting point 
[T1089]
21 May 2012 11:37:03:931 [DEBUG] [MXServer] [] Start validating branch:T1089
 - - - 
21 May 2012 11:37:03:932 [DEBUG] [MXServer] []  T1089 

Tasks 10 (T1085), 20 (T1086), and 30 (T1087) are all checked for loops.

21 May 2012 11:37:03:932 [DEBUG] [MXServer] []  T1085 
21 May 2012 11:37:03:932 [DEBUG] [MXServer] []  T1086 

Debug statements are output for successors Task 10 (T1085) and Task 20 (T1086). Task 30 (T1087) does not have a corresponding debug statement, which indicates that the error was encountered when Task 20 (T1086) was being validating.

21 May 2012 11:37:03:932 [DEBUG] [MXServer] [] 
Task 20 is causing a loop condition by connecting back to task:10.

The following diagram shows the validation process for the branch that is associated with Task 50. The error message indicates that the loop is created by Task 20. Task 20 is invalid because it is listed as a successor to Task 10 twice in the path definition.

The image is described in the text.



Feedback