Uploaded image for project: 'Grouper'
  1. Grouper
  2. GRP-4879

Full/Incremental overlap protection does not timeout

    XMLWordPrintable

Details

    • Bug
    • Resolution: Unresolved
    • Major
    • None
    • 2.6.19.3
    • provisioning
    • None

    Description

      Our ChangelogTemp processing was 24+ hours behind and to try to isolate the problem, we disabled "optional" jobs – loaders and provisioners – until things seem stabilized.

      We then got our loaders running.

      We then tried to get full-syncs running, but they seemed to not do anything theoretically because the Quartz and LoaderLogs tables still indicated that ancient copies of the jobs were running (when the daemons running them had long exited).

      After several efforts, we had to manually clean qz_fired_triggers and loader_logs which seemed to get the Full daemon jobs proceeding.

       

      This leads to the following suggestions:

      1. Better detection of orphaned jobs qz_fired_triggers, perhaps noticing that a running-job's instance_name is no longer in qz_scheduler_state
      2. A UI button in the Daemon-job panel that allows admins to mark a job as definitely not running
      3. Periodic logs (in log4j as well as in loader_logs, etc) when a Full is waiting for an Incremental to finish

      Attachments

        Activity

          People

            chris.hyzer@at.internet2.edu Chris Hyzer (upenn.edu)
            bert.beelindgren@at.internet2.edu Bert Bee-Lindgren (gatech.edu)
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

              Created:
              Updated: