Re: commit: ldap/servers/slapd backend.c
Hallvard B Furuseth wrote: > syncrepl.c accepts rids up to SLAP_SYNC_SID_MAX = 4095, > rather than up to SLAP_SYNC_RID_MAX = 999. > Also I suppose SLAPD_SYNC_SYNCCONN_OFFSET should be > -SLAP_SYNC_RID_MAX-1, so that constant is only hardcoded once. > (I don't know what a rid and a sid actually is though.) http://www.openldap.org/its/index.cgi/Archive.Development?id=5108;selectid=5108;usearchives=1 -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: commit: ldap/servers/slapd backend.c
syncrepl.c accepts rids up to SLAP_SYNC_SID_MAX = 4095, rather than up to SLAP_SYNC_RID_MAX = 999. Also I suppose SLAPD_SYNC_SYNCCONN_OFFSET should be -SLAP_SYNC_RID_MAX-1, so that constant is only hardcoded once. (I don't know what a rid and a sid actually is though.) -- Hallvard
Re: commit: ldap/servers/slapd backend.c
masar...@aero.polimi.it wrote: >> h...@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'. > > Right. Also, since o_connid is unsigned long, -1000-rid is a valid connid. > > Perhaps, a char in the Connection structure, or yet another value in some > bitmask would be better. Except that doesn't help the issue with syncrepl and slap_graduate_commit_csn(). Another suggestion is to reserve connids 0-999 for syncrepl, and start the real connections at 1000. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: commit: ldap/servers/slapd backend.c
> h...@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'. Right. Also, since o_connid is unsigned long, -1000-rid is a valid connid. Perhaps, a char in the Connection structure, or yet another value in some bitmask would be better. p.
Re: commit: ldap/servers/slapd backend.c
I wrote: > backend.c: 'op->o_connid <= -1000' is wrong. o_connid is unsigned long, > so this is compiled as 'op->o_connid <= (unsigned long) -1000'. Er... or maybe it's just the comment above the test which is wrong. -- Hallvard
Re: commit: ldap/servers/slapd backend.c
h...@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
Re: commit: ldap/servers/slapd backend.c
masar...@aero.polimi.it wrote: >> 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) Good idea. Go ahead. I'm still seeing a failure in test050 after 40-50 iterations, trying to track that down still. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: commit: ldap/servers/slapd backend.c
> 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.
Re: commit: ldap/servers/slapd backend.c operation.c proto-slap.h
[EMAIL PROTECTED] wrote: Update of /repo/OpenLDAP/pkg/ldap/servers/slapd Modified Files: backend.c 1.394 -> 1.395 operation.c 1.85 -> 1.86 proto-slap.h 1.751 -> 1.752 Log Message: ITS#5419 introduce OpExtra / op->o_extra to supersede op->o_private This code should probably use instead of the current approach. CVS Web URLs: http://www.openldap.org/devel/cvsweb.cgi/servers/slapd/ http://www.openldap.org/devel/cvsweb.cgi/servers/slapd/backend.c http://www.openldap.org/devel/cvsweb.cgi/servers/slapd/operation.c http://www.openldap.org/devel/cvsweb.cgi/servers/slapd/proto-slap.h Changes are generally available on cvs.openldap.org (and CVSweb) within 30 minutes of being committed. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sunhttp://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: commit: ldap/servers/slapd backend.c connection.c operation.c passwd.c sl_malloc.c
Hallvard B Furuseth wrote: > [EMAIL PROTECTED] writes: >> operation.c 1.81 -> 1.82 >> rename ldap_pvt_thread_pool_setkey_x() to >> ldap_pvt_thread_pool_setkey() (as part of ITS#5309) > > One nitpick - in this code in operation.c: > >>ldap_pvt_thread_pool_getkey( ctx, (void *)slap_op_free, &otmp, NULL ); >>op2 = otmp; >>LDAP_STAILQ_NEXT( op, o_next ) = op2; >>ldap_pvt_thread_pool_setkey( ctx, (void *)slap_op_free, >>(void *)op, slap_op_q_destroy, NULL, NULL ); > > can it be a problem if 'op' is stored to the context before its o_next > gets updated? It shouldn't be a problem, since by definition only one thread at a time can be calling it with that ctx. > If not, we can save a getkey call - move the setkey up > instead. I _think_ it's all right since only the current thread should > be accessing the key (except during pauses), and the pool can't pause > here. ditto. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: [EMAIL PROTECTED] ---
Re: commit: ldap/servers/slapd backend.c connection.c operation.c passwd.c sl_malloc.c
[EMAIL PROTECTED] writes: > operation.c 1.81 -> 1.82 > rename ldap_pvt_thread_pool_setkey_x() to > ldap_pvt_thread_pool_setkey() (as part of ITS#5309) One nitpick - in this code in operation.c: >ldap_pvt_thread_pool_getkey( ctx, (void *)slap_op_free, &otmp, NULL ); >op2 = otmp; >LDAP_STAILQ_NEXT( op, o_next ) = op2; >ldap_pvt_thread_pool_setkey( ctx, (void *)slap_op_free, >(void *)op, slap_op_q_destroy, NULL, NULL ); can it be a problem if 'op' is stored to the context before its o_next gets updated? If not, we can save a getkey call - move the setkey up instead. I _think_ it's all right since only the current thread should be accessing the key (except during pauses), and the pool can't pause here. -- Hallvard
Re: commit: ldap/servers/slapd backend.c backglue.c backover.c bconfig.c config.h proto-slap.h slap.h
Hi, Note, I just reworked that a bit I am now using a separate type as originally suggested by Ando. That seems to be the cleaner approach. On Wednesday 25 July 2007 17:28, Ralf Haferkamp wrote: > The BI_db_func()-functions (xxx_db_init, xxx_db_open, xxx_db_close and > xxx_db_destroy) now accept a ConfigArgs pointer as an additional argument. > I think I fixed all existing backends and overlays to accept the new > parameter (make test succeeded with --enable-backends=yes and > --enable-overlays=yes). > > Currently only back-monitor uses the new parameter for printing error > messages to the ca->msg attribute. I plan to update the other backends and > overlays next. > > On Wednesday 25 July 2007 17:21, [EMAIL PROTECTED] wrote: > [..] > > > Log Message: > > Added a new parameter (ConfigArgs*) to the _db_init, _db_open, _db_close > > and _db_destroy functions. > > [..] -- Ralf
Re: commit: ldap/servers/slapd backend.c backglue.c backover.c bconfig.c config.h proto-slap.h slap.h
The BI_db_func()-functions (xxx_db_init, xxx_db_open, xxx_db_close and xxx_db_destroy) now accept a ConfigArgs pointer as an additional argument. I think I fixed all existing backends and overlays to accept the new parameter (make test succeeded with --enable-backends=yes and --enable-overlays=yes). Currently only back-monitor uses the new parameter for printing error messages to the ca->msg attribute. I plan to update the other backends and overlays next. On Wednesday 25 July 2007 17:21, [EMAIL PROTECTED] wrote: [..] > Log Message: > Added a new parameter (ConfigArgs*) to the _db_init, _db_open, _db_close > and _db_destroy functions. [..] -- Ralf
Re: commit: ldap/servers/slapd backend.c
[EMAIL PROTECTED] wrote: Update of /repo/OpenLDAP/pkg/ldap/servers/slapd Modified Files: backend.c 1.378 -> 1.379 Log Message: ITS#4986 - remove special manageDSAit handing in select_backend() Of course this makes the manageDSAit parameter to select_backend() totally unnecessary. I guess I'll remove that soon as well. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sunhttp://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
