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/