RE24 (2.4.20) testing call #3
by Quanah Gibson-Mount
A few new changes, please re-sync and test. Thanks! Hopefully this will
be the last of it. In particular, watch test050 please. ;)
--Quanah
--
Quanah Gibson-Mount
Principal Software Engineer
Zimbra, Inc
--------------------
Zimbra :: the leader in open source messaging and collaboration
13 years, 6 months
RE24 (2.4.20) testing call #4
by Quanah Gibson-Mount
Testing call for 2.4.20 #4. This should be the last one. :P
Thanks!
--Quanah
--
Quanah Gibson-Mount
Principal Software Engineer
Zimbra, Inc
--------------------
Zimbra :: the leader in open source messaging and collaboration
13 years, 6 months
Java implementation of rfc4533 (Content Synchronization Operation)
by Joacim Breiler
Hi!
I've made an attempt to implement rfc4533 in Java using JLDAP based on
the work of Erik van Oosten's blog post:
http://day-to-day-stuff.blogspot.com/2007/11/howto-extend-ldap-in-java-wi...
I'm currently struggling with the RefreshOnly mode:
* On connect and the first search, a result with all entries is
returned together with a LDAPSyncStateControl.
* When the refresh i finnished, a LDAPSyncDoneControl is retreived and
the syncookie is saved for next search
* Next search is made using the saved syncookie, and I get no
additional results. Everything seems fine and dandy so far...
Now, if an entry is changed on OpenLDAP, a LDAPSearchResult is retreived
by the search, but doesn't contain the changed entry. I don't get the
LDAPSyncStateControl either. Any ideas?
The source of the controls and examples can be found here:
http://beskes.hgo.se/~joacimb/rfc4533/
Regards,
Joacim Breiler
13 years, 6 months
RE24 (2.4.20) testing call #3
by Quanah Gibson-Mount
Significant work done with replication issues. Please test, and
particularly test test050 and related a lot if possible.
Thanks!
--Quanah
--
Quanah Gibson-Mount
Principal Software Engineer
Zimbra, Inc
--------------------
Zimbra :: the leader in open source messaging and collaboration
13 years, 6 months
contextCSN of subordinate syncrepl DBs
by Rein Tollevik
I've been trying to figure out why syncrepl used on a backend that is
subordinate to a glue database with the syncprov overlay should save the
contextCSN in the suffix of the glue database rather than the suffix of
the backend where syncrepl is used. But all I come up with are reasons
why this should not be the case. So, unless anyone can enlighten me as
to what I'm missing, I suggest that this be changed.
The problem with the current design is that it makes it impossible to
reliably replicate more than one subordinate db from the same remote
server, as there are now race conditions where one of the subordinate
backends could save an updated contextCSN value that is picked up by the
other before it has finished its synchronization. An example of a
configuration where more than one subordinate db replicated from the
same server might be necessary is the central master described in my
previous posting in
http://www.openldap.org/lists/openldap-devel/200806/msg00041.html
My idea as to how this race condition could be verified was to add
enough entries to one of the backends (while the consumer was stopped)
to make it possible to restart the consumer after the first backend had
saved the updated contextCSN but before the second has finished its
synchronization. But I was able to produce it by simply add or delete
of an entry in one of the backends before starting the consumer. Far to
often was the backend without any changes able to pick up and save the
updated contextCSN from the producer before syncrepl on the second
backend fetched its initial value. I.e it started with an updated
contextCSN and didn't receive the changes that had taken place on the
producer. If syncrepl stored the values in the suffix of their own
database then they wouldn't interfere with each other like this.
There is a similar problem in syncprov, as it must use the lowest
contextCSN value (with a given sid) saved by the syncrepl backends
configured within the subtree where syncprov is used. But to do that it
also needs to distinguish the contextCSN values of each syncrepl
backend, which it can't do when they all save them in the glue suffix.
This also implies that syncprov must ignore contextCSN updates from
syncrepl until all syncrepl backends has saved a value, and that
syncprov on the provider must send newCookie sync info messages when it
updates its contextCSN value when the changed entry isn't being
replicated to a consumer. I.e as outlined in the message referred to above.
Neither of these changes should interfere with ordinary multi-master
configurations where syncrepl and syncprov are both use on the same
(glue) database.
I'll volunteer to implement and test the necessary changes if this is
the right solution. But to know whether my analysis is correct or not I
need feedback. So, comments please?
--
Rein Tollevik
Basefarm AS
13 years, 6 months
Re: commit: ldap/servers/slapd config.c
by Hallvard B Furuseth
ando(a)OpenLDAP.org writes:
> config.c 1.506 -> 1.507
> silence signedness warnings
>
> - } else if ( rc == ARG_BAD_CONF ) {
> + } else if ( (unsigned long)rc == ARG_BAD_CONF ) {
That breaks working code. Never shut up signedness warnings without
working through what the expressions do, it's too easy to go wrong.
rc is an int.
ARG_BAD_CONF = 0xdead0000: an unsigned int if int is 32-bit.
Consider 32-bit int, 64-bit long, with rc == (int)ARG_BAD_CONF:
rc < 0 so (unsigned long)rc sign-extends to 0xffffffffdead0000,
but ARG_BAD_CONF itself is positive so it is not sign-extended.
The old code worked as far as I can tell: It converted rc to unsigned
int, yielding the original ARG_BAD_CONF.
The same functinality change happens with the other changes below that
one, I haven't looked at whether that is a fix of broken code or if it
breaks working code. (Or it is breaks broken code in a new way:-)
--
Hallvard
13 years, 6 months
Re: commit: ldap/servers/slapd backend.c
by Hallvard B Furuseth
hyc(a)OpenLDAP.org writes:
> backend.c 1.412 -> 1.413
> ITS#6393 syncrepl internal connids are now <= -1000
backend.c: 'op->o_connid <= -1000' is wrong. o_connid is unsigned long,
so this is compiled as 'op->o_connid <= (unsigned long) -1000'.
I haven't looked at possible connid values, but maybe you want
o_connid >= (unsigned long)-1000.
--
Hallvard
13 years, 6 months
Re: commit: ldap/servers/slapd backend.c
by masarati＠aero.polimi.it
> Update of /repo/OpenLDAP/pkg/ldap/servers/slapd
>
> Modified Files:
> backend.c 1.412 -> 1.413
>
> Log Message:
> ITS#6393 syncrepl internal connids are now <= -1000
What about checking this through a macro?
#define SLAPD_SYNC_CONN_OFFSET (-1000)
#define SLAPD_SYNC_CONN(connid) ((connid) <= SLAPD_SYNC_CONN_OFFSET)
p.
13 years, 6 months
