Grouper Users - Open Discussion List

["Black, Carey M." <>]

James,

Thanks for the data point.
I expect ( based on limited testing ) that I could likely run this much more 
frequently than that for my environment. But I am also not really using this 
feature yet too.

However the gap between "3 times a day" ( the default ) and "96 times a day" 
(every 15 min) or even "288 times a day" (every 5 min) is fairly large. 

So I thought I would ask before I jumped in the deep end on this one. :)
        I really want to ultimately do these changes "every second". ( I 
doubt that is wise in the current design. ) 
        And I really want the changes to be "independent" instead of "a 
single, possibly large, queue" too.



FWIW: REF: https://bugs.internet2.edu/jira/browse/GRP-1915

All,

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 it could verify the status as "good" then quit 
or correct. ( if that is knowable. Not sure it can be known. )
 
-- 
Carey Matthew 


-----Original Message-----
From: James Babb 
<>
 
Sent: Wednesday, September 26, 2018 12:56 AM
To: Hyzer, Chris 
<>;
 Black, Carey M. 
<>
Cc: 

 Mailing List 
<>
Subject: Re: [grouper-users] RE: RE: MAINTENANCE__enabledDisabled

Wisconsin runs MAINTENANCE__enabledDisabled job every 15 minutes so future 
dated memberships will take effect within 15 minutes of whatever time someone 
scheduled it for. Hasn't caused a problem so far since I increased how often 
it ran a few months ago. 


On 9/23/18, 11:36 PM, 
"
 on behalf of Hyzer, Chris" 
<
 on behalf of 
>
 wrote:

    We can probably do better than this... maybe open a jira with 
requirements and we can think about it.  Run as often as you like and monitor 
performance and let us know how it goes 😊
    
    Thanks
    Chris
    
    
    -----Original Message-----
    From: 

 
<>
 On Behalf Of Black, Carey M.
    Sent: Friday, September 21, 2018 2:05 PM
    To: 

 Mailing List 
<>
    Subject: [grouper-users] RE: MAINTENANCE__enabledDisabled
    
    All, 
    
    I note that the "default" schedule for this job is only 3 times a day.
        REF: 
https://spaces.at.internet2.edu/display/Grouper/Grouper+enabled+and+disabled+dates
        " #leave blank to disable this, the default is 12:01am, 11:01am, 
3:01pm every day "
    
    Which I understand ("parse") as "overnight", "before lunch" and "toward 
the end of the day". 
    
    Is there a performance concern with running this much more frequently? ( 
Example: every minute? Every 5 minutes? Every 15 minutes?)
    
    -- 
    Carey Matthew