Skip to content


jodzga edited this page Dec 7, 2015 · 15 revisions
Clone this wiki locally

ParSeq provides a couple of mechanisms for observing the execution of tasks. We have a mechanism for capturing traces, serializing as JSON data and rendering them. We also have logging facilities.

JSON Trace

Getting a Trace

At any time (even mid-execution) it is possible to ask a Task for its trace information, using the following interaction:

final Task<String> task = ...;;
final Trace trace = task.getTrace();

The Trace object includes information about the task such as its name, when it was started and completed, it may include its value (see setTraceValueSerializer() method) and references to tasks that are related to the task. See the Trace javadoc for details.

Saving the Trace as JSON

ParSeq can serialize a trace to JSON using the following code:


This will produce an output that has the following basic structure:

  "traces": [
      "id": 5,
      "name": "printResults",
      "resultType": "SUCCESS",
      "hidden": false,
      "systemHidden": false,
      "startNanos": 1.3486979401871e+18,
      "endNanos": 1.3486979401876e+18
      "id": 0,
      "name": "seq",
      "resultType": "SUCCESS",
      "hidden": false,
      "systemHidden": true,
      "startNanos": 1.3486979400423e+18,
      "endNanos": 1.3486979401876e+18
  "relationships": [
      "relationship": "PARENT_OF",
      "from": 0,
      "to": 5

ParSeq Trace Tools

ParSeq has some tools for inspecting a trace.

To use the tools, navigate to contrib/parseq-tracevis-server in the source tree and follow the instructions in the README.

Once you have the trace visualization server up, copy the JSON trace into the "Insert JSON trace here" box. If you just want to try out the viewer, you can copy JSON trace below (which is also used to generate the visualization examples further down in this document).


The trace tool allows some basic filtering:

  • User hidden tasks when checked - shows tasks that user code indicated should not be displayed. This is unchecked by default, but can be checked to get a complete view of an execution.

  • System hidden tasks when checked - shows tasks that the ParSeq system indicated should not be displayed. This is unchecked by default to make it easier to see user tasks without the clutter of system tasks.

  • Parent tasks when checked - shows tasks that contains other tasks. In other words, with this option unchecked you will only see leaf tasks (tasks with no children). This option is checked by default.

Each of the views uses a color scheme to indicate the status of a task.

  • Green indicates success
  • Red indicates an error
  • Yellow indicates that a task was cancelled with EarlyFinishException because its parent finished before the task itself finished
  • Gray indicates a task that was not finished (either successfully or with an error) at the time the trace was taken

Waterfall View

The waterfall view shows how long each task took to complete. Parent tasks, marked with little black triangles, are collapsable/expandable.Hovering over parent task greys out all tasks that are not one of its descendants. This view can give you a sense for which tasks in the graph took the most time to execute.


Graphviz View

The graphviz view shows detailed information about relationship between tasks.

The output (including System hidden tasks) looks like the following:


You can interactively zoom in/out as well as pan the view to see in details particular part of the diagram. Use mouse, mousewheel, touchpad or zoom/pan control.

Additionally time slider control helps you undesrtand how the plan progressed through time. We accurately measure when task was started and when it was finished but we dont measure it progress during the execution. This visualization interpolates completeness of each task based on its start and stop time e.g. if task started at 3ms and finished at 7ms it will show that task was 75% complete when slider is at 6ms.


Below is detailed description of elements of the diagrams generated in Graphviz View.

Tasks are represented as nodes in the graph.


They have a (1) name, a box with (2) @start-time, (3) self-time and (4) +elapsed-time. The start-time indicates when the task started in milliseconds relative to the start of the root task. The self-time indicates amount of time spent in ParSeq thread. The elapsed-timestamp indicates the time elapsed from the start of the task to the time it completed.

Edges between tasks indicate ordering.


For example, in the graph above fetch task was run after id task.

In some cases you may see a dashed line between tasks. This indicates that one task was declared to run after the other, but when the plan was executed the successor task was executed due to some other reason (like the completion of another task).

Parent tasks are tasks that trigger the execution of one or more child tasks. They are represented in the graph as a box with a dashed edge.


Like normal tasks, they have a (1) name, (2) @start-time, (3) self-time and (4) +elapsed-time. They also contain all of their child tasks - HEAD in example above.

Parent tasks have a grey circle that represents where a parent task was started. They have a double circle to indicate where they finished. Color of double circle indicates the result type of the parent task.


An edge from a grey circle - known as a source - to a task indicates that the task was kicked off as a direct result of executing the parent task. In example above withTimeout 10 ms task directly caused execution of timeoutTimer task and GET task.

An edge from a task to a double circle - known as a sink - indicates that the task was one of the final tasks run before finishing the parent task. In example above timeoutTask was final task run before finishing teh parent task.

In some cases an edge between a task and a sink will be dashed. This indicates that parent task did not wait for completion of that task. In example above timeoutTimer task failed the parent task with TimeoutException (notice red color of double circle) before GET finished (dashed line between the child task and double circle means that parent finished before the child, moreover: yellow color means that GET task was cancelled with EarlyFinishException).

You may sometimes see dashed edge between source and a task that is located outside th eparent task.


This indicates that the task could have been run by the parent task but was actually run in some other way - by different parent task or even in the context of different plan. In example above update task would have run log in task but it already has run in the context of a different plan.

Table View

The table view is a text representation of the JSON trace. This is the only view that shows a text representation of the result of a task (as serialized by setTraceValueSerializer() method).



We have 3 types of loggers that log basic events as they occur:

  1. Log events for root tasks
    • Set logger "com.linkedin.parseq.Engine:root" to DEBUG or TRACE.
    • A root task is a task that is given to an Engine with
    • This loggers helps to get a sense for how long plans take to run without generating large volumes of logs.
  2. Log events for plan tasks
    • Set logger "com.linkedin.parseq.Engine:planClass=XTask" to DEBUG or TRACE.
    • When executed by the planClass is simply a class name of the task being executed. This is particularly usefule with ParSeq v1.x where new tasks were created mostly through class inheritance. In ParSeq 2.x it is possible to specify planClass when passing task to engine, planClass) where planClass is an arbitrary String that will be mapped to a logger.
    • When the root task is of type XTask this logger will log events for XTask and any tasks that are transitively executed (i.e. its child tasks, their child tasks, etc.).
    • This logger helps to get a deeper understanding of each step taking during the execution of a particular plan.
  3. Log events for all tasks
    • Set logger "com.linkedin.parseq.Engine:all" to DEBUG or TRACE
    • This logs events for every tasks that is executed.
    • This logger can be quite verbose, so logger #1 and #2 above should be preferred where appropriate.

At the DEBUG level, loggers will log the following events:

2012-09-26 15:18:16,910 [plan=0]: Starting task 'fetch[url=]'
2012-09-26 15:18:16,994 [plan=0]: Ending task 'fetch[url=]'. Elapsed: 81ms, Result type: SUCCESS.

At the TRACE level, loggers will log the following events:

2012-09-26 15:19:00,055 [plan=0]: Starting task 'fetch[url=]'
2012-09-26 15:19:00,101 [plan=0]: Ending task 'fetch[url=]'. Elapsed: 42ms, Result type: SUCCESS. Value: <!doctype html><html>...
Something went wrong with that request. Please try again.