> > * if the virtual machine has only one CPU. Adding a second
CPU increases
> > the
> > number of transferred entries before the initialization gets stuck. So it
> > may me some thread/transaction contention or deadlock.
>
> > * if the replication agreement uses SSL(port 636) or TLS(port389). Using
> > port
> > 389 with LDAP protocol instead of TLS/SSL increases the number of
> > transferred entries before the initialization gets stuck. Sometimes the
> > initialization even ends successfully in this case.
>
> > * decreasing nsslapd-db-checkpoint-interval (say, to 5 seconds) also gets
> > the
> > problem worse
>
> This indicates the issue is in the BDB?
Don't know. My hypotheses are :
* using plugin transactions compared to 1.2.10.x
* bdb version? but even with compat-db-47 and 1.2.10 the problem still
happens on CentOS7, though much less frequently. It never happens with
1.2.10 with rpm bdb on CentOS5.
* change from mozilla ldap libraries to openldap libraries?
seems to be some sort of thread or transaction contention that is
reduced
when i add CPUs/increase checkpoint interval. It really looks like the
master server just does not send entries any more at some moment... SSL/TLS
slows the things down so less entries are sent before everything gets
stuck...
I'll get back with more information (stacktraces) tomorrrow.
Another version :
insufficient entropy generation speed for TLS/SSL total update (/dev/urandom vs blocking
/dev/random), especially in VMs??