Flexibility in Job Monitoring


  • with 100s of active jobs in the repository, it's too long to wait for the status updates of the user's preferred jobs
  • startup time may sometimes be affected (prompt blocked) on the monitoring actions

We need more of control over which jobs are monitored (or prioritized).

Existing GPI interface to monitoring on demand:

runMonitoring(self, steps=1, timeout=60)
    Enable/Run the monitoring loop and wait for the monitoring steps completion.
      steps:   number of monitoring steps to run
      timeout: how long to wait for monitor steps termination (seconds)
      False, if the loop cannot be started or the timeout occured while waiting for monitoring termination
      True, if the monitoring steps were successfully executed  
      This method is meant to be used in Ganga scripts to request monitoring on demand.

The monitoring may be enabled/disabled at startup:

config.PollThread.autostart = True|False

For interactive sessions the monitoring is enabled on startup by default, for batch sessions (ganga script) the monitoring is disabled by default .


If you want to have more control on monitoring you:

  • disable monitoring at startup (new option? --no-monitoring? <=> PollThread.autostart=False)
  • to update last 10 jobs run: enableMonitoring(jobs=jobs[-10:])
  • then you may add more high-priority jobs to monitor enableMonitoring([j[1],j[2],...)

-- JakubMoscicki - 12 Feb 2009

Edit | Attach | Watch | Print version | History: r1 | Backlinks | Raw View | WYSIWYG | More topic actions
Topic revision: r1 - 2009-02-12 - JakubMoscicki
    • Cern Search Icon Cern Search
    • TWiki Search Icon TWiki Search
    • Google Search Icon Google Search

    ArdaGrid All webs login

This site is powered by the TWiki collaboration platform Powered by PerlCopyright & 2008-2022 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
or Ideas, requests, problems regarding TWiki? use Discourse or Send feedback