Skip to Content.
Sympa Menu

grouper-dev - Re: [grouper-dev] ldap errors and real time provisioning

Subject: Grouper Developers Forum

List archive

Re: [grouper-dev] ldap errors and real time provisioning

Chronological Thread 
  • From: "Michael R. Gettes" <>
  • To: Gagné Sébastien <>
  • Cc: Lynn Garrison <>, Grouper Dev <>
  • Subject: Re: [grouper-dev] ldap errors and real time provisioning
  • Date: Thu, 31 May 2012 14:16:48 +0000
  • Accept-language: en-US

what kind of "bad data" are you considering?


On May 31, 2012, at 9:56, Gagné Sébastien wrote:

> I agree that would be an interesting feature, but the reaction should
> depend on the LDAP error. Some errors could be because of bad data in one
> record and these shouldn't block the provisioning of all the other
> changelog. I think this is where an error queue might be useful; you try
> them all and if one has bad data, it will be in the error queue to retry
> later, but all the others will still complete successfully. Of course if
> the ldap server has a problem you'll have a huge error queue, but they
> would have been waiting in the changelog anyway. I think it's important for
> the error queue to be retried periodically
> There's the PSP daily full sync that kinda solves this problem. If you
> enable it, all the failed transactions will be synched later when the ldap
> server will be back online. I believe this sync isn't based on the
> changelog but on a diff between Grouper and the LDAP.
> -----Message d'origine-----
> De :
> [mailto:]
> De la part de Michael R. Gettes
> Envoyé : 31 mai 2012 09:31
> À : Lynn Garrison
> Cc : Grouper Dev
> Objet : Re: [grouper-dev] ldap errors and real time provisioning
> +1 to this request. failures should block processing. i view this similar
> to data replication - the idea is to keep the data in sync and if there are
> problems in the sync process, they should block, or, in the very least, be
> placed into an error queue. I hate the error queue notion but I do realize
> lots of products do things this way these days.
> /mrg
> On May 31, 2012, at 9:26, Lynn Garrison wrote:
>> Is there a way to stop the real time provisioning if there are
>> problems with the ldap server? We moved to testing real time
>> provisioning with openldap. During the provisioning testing, the file
>> system became full and ldap updates started returning errors.
>> 2012-05-31 09:15:16,001: [DefaultQuartzScheduler_Worker-8] ERROR
>> BaseSpmlProvider.execute(388) - - Target 'psp' - Modify XML:
>> <modifyResponse xmlns='urn:oasis:names:tc:SPML:2:0' status='failure'
>> requestID='2012/05/31-09:15:15.993' error='customError'>
>> <errorMessage>[LDAP: error code 80 - commit failed]</errorMessage>
>> </modifyResponse>
>> psp continued to process the change log events. By the time we
>> realized what was happening, all the change log events had been processed
>> and only have the members were provisioned to the group.
>> Lynn

Archive powered by MHonArc 2.6.16.

Top of Page