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

enable/disable membership process per second

    XMLWordPrintable

Details

    • New Feature
    • Status: Open
    • Minor
    • Resolution: Unresolved
    • None
    • None
    • grouperLoader
    • None
    • 2.3

    Description

      I really don't like "batch jobs" ( in general ) so this kind of "queue" really is not ideal. (IMHO)

      For my taste (AKA: " requirements ")  I would rather see a scheduled job to run at the "enable/disable" date for the specific membership change data and have quarts just "run the job of one" at that time.

      So the system stacks up as many of those as are needed based on the system's use of the feature(dates on memberships). And checks/corrects each one when they are scheduled.

       

      What I don't know is:

      if those scheduled jobs are "in RAM"(Which I suspect) or stored in the DB at this point.

      Specifically I think the "running jobs" are written to the DB, but only just before they are "started" by a loader. ( The "loader properties" (on groups/folders?)  and "loader config" data is the serialized future schedule.)

      I think the future scheduled jobs would need to be in the DB to do what I want.

      To trigger at the "specified time". AKA: At the selected second.

      And to deal with "no loaders running" and a loader finally starts up ( What ones do I need to process?)

       

      So my suggestion is to:

      ]  Have a "job of one" scheduled when the dates are set/changed. (and stored the jobs in the DB as a queue/plan of future work for a loader.)

      Likely two variates of jobs. One for "enableAt" and a separate one for "disableAt". (Created based on the changing of the start/end dates.)

      ] the "job of one" ( at run time) looks at the referenced membership and decides if the membership date match expected value in the job and the data is now (or "in the past"), then do it. (  Enable or Disable events fire in Grouper for the membership. )

      Basically

      if the membership still looks like it should (based on current date(s) in the membership then run.

      If, not then some other job should have been scheduled (before or after this on) to "do the right thing" so back off.

      Or I guess if the job could verify the status as "good" then quit or correct it. ( if that is knowable. Not sure it can be known. )

       

      Thanks in advance.

      Attachments

        Activity

          People

            chris.hyzer@at.internet2.edu Chris Hyzer (upenn.edu)
            carey.black@at.internet2.edu Carey Black (osu.edu)
            Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

              Created:
              Updated:

              Smart Checklist