Re: (ITS#6320)

[j@telepaths.org]

On Oct 2, 2009, at 23:00 , Howard Chu wrote:

> j@telepaths.org wrote:
>> My last email was likely indecipherable, so re-sending as plain text:
>>
>> #####
>>
>> This may sound like a strange question, but couldn't seem to find the
>> answer in the docs:
>>
>> Would the global "idletimeout" parameter interfere with
>> 'refreshAndPersist' operations in any way?
>
> No, that would be stupid.
>
Yes Howard -- that would be incredibly stupid. But I had to ask.

>> I ask because I have had yet another instance where my three
>> production consumers did not get a series of updates that it should
>> have.  This was hours after successfully adding an accesslog database
>> to all Provider servers in question.
>>
>> When querying the log database:
>>
>> ldapsearch -b cn=log -xD uid=log,cn=log -w logpassword -s sub -H ldap://ldap-provider-in-question
>>
>> I see that the records-in-question were in fact updated as they  
>> should
>> have .... but there's absolutely no information hinting towards WHY a
>> remote server would fail to get updates (especially when all LDAP
>> traffic in between the said-hosts is unrestricted and unmoderated).
>
> Are you sure? No firewalls in the way?
>
SOME of the servers receiving updates are separated by firewalls,  
yes ... HOWEVER (a) there are special policies in place, allowing  
these hosts to communicate via LDAP[S]; this can be confirmed by  
running ldapsearch routines from every possible vantage point TO every  
possible provider, etc., and (b) some of the replication issues  
observed occurred when all affected hosts (one or more providers and  
its consumer clients) were in the same local subnet, at which point  
the firewall is immaterial.

I had asked my stupid question about the idletimeout, because this  
behavior doesn't strike me as simply "not working".  Rather, it begins  
to work .... then just stops.  So my next thought was that perhaps the  
firewall was causing the connections to time-out.  But if that were  
true ... wouldn't both the "retry" and the "timeout" parameters  
compensate for this?  I mean, the man page certainly doesn't  
contradict my assumption ...

Jeff


>> Hence why I began to scrutinize the 'idletimeout' parameter
>> (previously set to 45 seconds, now has been removed entirely from all
>> Providers AND Consumers alike).
>>
>> Still looking at, testing and contemplating this whole situation ...
>> I'll keep you posted, but am curious if anyone has any input to my
>> question above, thanks.
>>
>> #####
>>
>> I am officially out of ideas - synchronization is entirely  
>> unreliable.
>> Need guidance ASAP. Thanks .....
>
> -- 
>  -- Howard Chu
>  CTO, Symas Corp.           http://www.symas.com
>  Director, Highland Sun     http://highlandsun.com/hyc/
>  Chief Architect, OpenLDAP  http://www.openldap.org/project/