Grouper Developers Forum

["Michael R. Gettes" <>]

what kind of "bad data" are you considering?

/mrg

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
>> 
>> 
>