[Date Prev][Date Next]
On Oct 2, 2009, at 23:00 , Howard Chu wrote:
> email@example.com 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
>> 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 ...
>> 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
>> 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/