kn99hn / pogger Goto Github PK

Parse all the trace files: trace-* and carry out the reconciliation logic with vector clock.

Each Event type in the trace file should have timestamp = process_name:path_id:vector_clock. The vector clocks of each event can be reproduced easily in this case.

Using the vector clock, it can be determined which event happened before and after. All the paths can be parsed into a Graph with edges, indicating a happened before relationship. This will be useful when we do DFS validation logic later on.

Checker should takes in an "expectation tree" created from #4 and a "trace tree" produced after reconciliation #2.

While traverse the expectation tree, we will run the check function for each expectation statement. The possible-match result of each check function will form a search tree, with the height equals to the number of expectation statement ad width dependent on the number of variant statement.

The Checker should carry out DFS on the search tree, to check if there exists a leaf node that reaches the end of the expectation tree and the trace tree at the same time.

For each supported expectation statement, we will create a check function. The check function takes a tree node in the trace tree and return possible number of events it could match in the given subtree.

• task
• send
• recv
• repeat
• maybe

Part of #6

Part of #6.

• Ensure that the debugger is able to validate different traces given expectations.
• We will measure how many traces we are able to validate, how many traces we are unable to validate and how many false positives or negatives we identify (if any)

Validator module represent the parsing of validator language:

Validator {
    Process_name: {
       repeat between 1 and n {

      },
      maybe {

      }
   }
}

Annotation module allows users to add annotation to their applications and allow us to record unique path for each trace.

Path {
  path_id
 events: [Event]
}

Event = Task | Notice | Message

Task {
  name
  timestamp
  Task
}

Notice {
  name
  timestamp
}

Message {
  message_type
  message_id
  message_size
  timestamp
}

timestamp = process_name:path_id:vector_clock_value
message_type = send | receive

Functions:
- init(): initialize the state, create trace files. This should utilize Agent in elixir
- set_path_id: set path id for current path <- using random hash
- start_task, end_task: should be accompanied each other of a task
- notice(string): record a log message
- send(...)/receive(...): message_id and message_size must be the same for 1-1 send/receive messages

• Measure latency of adding annotations on the applications
• Validate if our work is correct using an ADT FIFO queue with multiple distributed enq and deq commands.

I think JSON makes the most sense here since it's easy to parse and write with built in lib.

JSON:

Task: {
   timestamp: a:path_1: 1,
    name: busy,
    Task: {
         ....
     }
}
Send: {
   timestamp: a:path_1: 3,
    message_size: ....
}
Notice {
   timestamp: a:path_1:5,
   message: This is a log message
}

Pros: Easy to write and parse because we can use built in lib from elixir to write and parse JSON objects.
Cons: Take up lots of space