(ITS#6444) OpenLDAP 2.5 RoadMap Question

[j@gropefruit.com]

Full_Name: J
Version: 2.4.20
OS: Debian/Lenny-AMD64
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (207.67.92.30)


Please clarify this statement in your 2.5 roadmap:

LDAPv3 extensions:
 *LDAP Transaction support 

Do you mean that SyncRepl will actually become legitimately enterprise-class, in
that replication will work 100% of the time?  Or does this mean transaction
support for some other element unrelated to content synchronization?

Why I ask:

I've opened a few tickets on OpenLDAP in the past, related to replication issues
involving multiple multimaster servers with a frontend employed (a hardware load
balancer) to control writes.  From time to time, it seems as though SyncRepl
just "decides" to fail, and gives no indication ANYWHERE as to why.  We log all
sync activity, and we see no indication that the host is unreachable or down,
and we see no performance delays when querying the DSAs manually.

* All slapd servers' clocks are perfectly synchronized and are in a common time
zone
* Of all six multimasters, only two of them actually receive WRITES
* All are 2.4.20 on amd64 kernel (Debian Lenny)
* We see no discernible improvement when switching from refreshOnly to
refreshAndPersist.

Replication will work fine for awhile (in the most recent case, it worked for 16
days, having written test records ranging from 1000 to 50000 *repeatedly*
without issues) and then just "fail" ....

We have ruled out the following:

* Bad hardware
* slapd Configuration error (have posted our config before)
* Firewall timeout issues for cross-site replication (a timeout wouldn't wait 16
days)
* Firewall policies between sites (wouldn't cause it to work and then not
work).
* slapd segfaulting or crashing in some way

This behavior is quite lackluster for a business environment and is ultimately
insufficient for any legitimate application.  As far as I am concerned, the
results are so unbelievably inconsistent that this is an affront to the way
SyncRepl is represented/advertised.  If it NEVER worked at all, at least THAT
would be consistent.  

SyncRepl rarely makes any valid attempt to "sync up" when differences are
detected between DSAs  -  SOMETIMES it feels like it, most of the time it does
not.   I hate to say it, but SyncRepl is a huge pile of misrepresentation and
broken promises.

So:  Is transaction support intended to SOLVE these issues?  If not, maybe you
should invent something to replace SyncRepl altogether.

J