Skip to Content.
Sympa Menu

grouper-dev - Re: [grouper-dev] [ldappcng] real-time & batch scheduling and clobbering avoidance ?

Subject: Grouper Developers Forum

List archive

Re: [grouper-dev] [ldappcng] real-time & batch scheduling and clobbering avoidance ?


Chronological Thread 
  • From: "McDermott, Michael" <>
  • To: Tom Zeller <>
  • Cc: Grouper Dev <>
  • Subject: Re: [grouper-dev] [ldappcng] real-time & batch scheduling and clobbering avoidance ?
  • Date: Wed, 28 Sep 2011 05:06:24 -0400

Locally we are looking at solving this problem with the change log and a queue for exactly this reason.  We're using a an independent, remote queue, but as I read the features of ActiveMQ (Apache's JMS offering), you can embed it and use it as part of an application.  To paraphrase a quip about regular expressions:  'You come across a problem where it seems like you can setup a simple queue in a database; now you have two problems.'



On Tue, Sep 27, 2011 at 10:48 PM, Tom Zeller <> wrote:
How do we want to schedule real-time and batch provisioning ?

Currently, ldappcng has

 -interval <seconds>

and

 -intervalFullSync <seconds>

command line options to control how often provisioning runs are performed.

The -interval <seconds> option looks at lastModifyTime to determine if
objects should be updated, and I think we will discontinue this in
lieu of the changelog.

So, I assume, every few (configurable) seconds ldappcng will provision
(incrementally) based on the changelog.

And, I assume, deployers will want to schedule batch / full sync
provisioning runs at night (or maybe more often) to make sure
everything is properly provisioned.

However, let us assume a situation where a full sync of a large group
takes a long time (e.g. 1 minute). During the full sync of the large
group, membership changes might occur, which will be queued in the
changelog. After the full sync of the large group is finished and we
begin processing the changelog, we should not process changelog
entries that were queued before the group was fully synchronized but
after the full sync was started. So, I think we will need to store the
last update time of provisioned objects to not clobber ourselves.

We may also want to (optionally) schedule a full sync of a provisioned
object if provisioning incrementally based on the changelog
experiences an error.

What do you think ?

Thanks,
TomZ



--
Michael J. McDermott
Lead Developer, Identity and Access Management
Brown University





Archive powered by MHonArc 2.6.16.

Top of Page