1. 15 Jul, 2010 1 commit
    • Michael Hanselmann's avatar
      jqueue: Factorize code waiting for job changes · 989a8bee
      Michael Hanselmann authored
      By splitting the _WaitForJobChangesHelper class into multiple smaller
      classes, we gain in several places:
      - Simpler code, less interaction between functions and variables
      - Easy to unittest (close to 100% coverage)
      - Waiting for job changes has no direct knowledge of queue anymore (it
        doesn't references queue functions anymore, especially not private ones)
      - Activate inotify only if there was no change at the beginning (and
        checking again right away to avoid race conditions)
      Signed-off-by: default avatarMichael Hanselmann <hansmi@google.com>
      Reviewed-by: default avatarGuido Trotter <ultrotter@google.com>
  2. 12 Jul, 2010 1 commit
  3. 09 Jul, 2010 1 commit
  4. 06 Jul, 2010 1 commit
    • Iustin Pop's avatar
      Fix opcode transition from WAITLOCK to RUNNING · 271daef8
      Iustin Pop authored
      With the recent changes in the job queue, an old bug surfaced: we never
      serialized the status change when in NotifyStart, thus a crash of the
      master would have left the job queue oblivious to the fact that the job
      was actually running.
      In the previous implementation, queries against the job status were
      using the in-memory object, so they 'saw' and reported correctly the
      running status. But the new implementation just looks at the on-disk
      version, and thus didn't see this transition.
      The patch also moves NotifyStart to a decorator-based version (like the
      other functions), which generates a lot of churn in the diff, sorry.
      Signed-off-by: default avatarIustin Pop <iustin@google.com>
      Reviewed-by: default avatarMichael Hanselmann <hansmi@google.com>
  5. 28 Jun, 2010 6 commits
  6. 23 Jun, 2010 6 commits
  7. 17 Jun, 2010 4 commits
  8. 15 Jun, 2010 2 commits
  9. 11 Jun, 2010 6 commits
  10. 01 Jun, 2010 1 commit
    • Iustin Pop's avatar
      Add a new opcode timestamp field · b9b5abcb
      Iustin Pop authored
      Since the current start_timestamp opcode attribute refers to the inital
      start time, before locks are acquired, it's not useful to determine the
      actual execution order of two opcodes/jobs competing for the same lock.
      This patch adds a new field, exec_timestamp, that is updated when the
      opcode moves from OP_STATUS_WAITLOCK to OP_STATUS_RUNNING, thus allowing
      a clear view of the execution history. The new field is visible in the
      job output via the 'opexec' field.
      Signed-off-by: default avatarIustin Pop <iustin@google.com>
      Reviewed-by: default avatarGuido Trotter <ultrotter@google.com>
  11. 08 Mar, 2010 2 commits
  12. 13 Jan, 2010 4 commits
  13. 04 Jan, 2010 4 commits
  14. 28 Dec, 2009 1 commit