8:02 a.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 04/04/2012 03:26 PM, hyc(a)symas.com wrote:
See ITS#7225.
Even after the SEGV is patched, the pcache slapd fails to start in test020
because the monitor calls are unable to register their entries. Something is
wrong in your initialization code.
When the ldap database is opened before the monitor, all registration is
deferred and fake OK status is returned. Then, while the subsystems are
initializing, the new subsystems (that have to derive their DN from
something) do not yet have access to the DN of the database monitor
entry (even though it may already exist). Only after all subsystems have
been opened does the deferred database registration proceed, but by then
there is no way to notify anyone that the DN has been published. Thus we
are left with a chicken-and-egg problem.
One way out of this I currently see is providing a register_database
callback that is called immediately when no deferring takes place or
immediately after the entry in limbo_queue has been processed. This way
once the DN information is ready, the subsystem registration can start
safely.
There is an alternative, adding a defferable monitor_subsys registration
(and alimbo entry type) that, if monitor is not opened, takes place in
the second phase (roughly at the same time as above).
There are aspects in which either one is cleaner, whereas the other one
can backfire/clutter the API and vice versa for others. I have not
decided yet.
Also, you're using monitor_entry_stub() directly in the back-ldap
code. It is
forbidden for modules to directly reference each other's symbols. If you need
this function, add it to monitor_extra_t first and call it through there.
Thank you, I will. And sorry for breaking master with this ITS.
- --
Ondrej Kuznik
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk99tAoACgkQ9GWxeeH+cXvgsACdGx7/7Wp1h/Ye5voKcQhHDVPa
FXQAnAodz5i9e6ReWwgkeNPbPsxQhN/V
=FTRg
-----END PGP SIGNATURE-----
This e-mail and any attachment is for authorised use by the intended recipient(s) only. It
may contain proprietary material, confidential information and/or be subject to legal
privilege. It should not be copied, disclosed to, retained or used by, any other party. If
you are not an intended recipient then please promptly delete this e-mail and any
attachment and all copies and inform the sender. Thank you for understanding.
6:46 a.m.
New subject: (ITS#7182) back-ldap monitoring improvements
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 04/04/2012 03:26 PM, hyc(a)symas.com wrote:
> See ITS#7225.
>
> Even after the SEGV is patched, the pcache slapd fails to start in
> test020
> because the monitor calls are unable to register their entries.
> Something is
> wrong in your initialization code.
When the ldap database is opened before the monitor, all registration is
deferred and fake OK status is returned. Then, while the subsystems are
initializing, the new subsystems (that have to derive their DN from
something) do not yet have access to the DN of the database monitor
entry (even though it may already exist). Only after all subsystems have
been opened does the deferred database registration proceed, but by then
there is no way to notify anyone that the DN has been published. Thus we
are left with a chicken-and-egg problem.
One way out of this I currently see is providing a register_database
callback that is called immediately when no deferring takes place or
immediately after the entry in limbo_queue has been processed. This way
once the DN information is ready, the subsystem registration can start
safely.
There is an alternative, adding a defferable monitor_subsys registration
(and alimbo entry type) that, if monitor is not opened, takes place in
the second phase (roughly at the same time as above).
There are aspects in which either one is cleaner, whereas the other one
can backfire/clutter the API and vice versa for others. I have not
decided yet.
> Also, you're using monitor_entry_stub() directly in the back-ldap code.
> It is
> forbidden for modules to directly reference each other's symbols. If you
> need
> this function, add it to monitor_extra_t first and call it through
> there.
Thank you, I will. And sorry for breaking master with this ITS.
I think the problem (and the patch) can be greatly simplified and made
clearer by totally eliminating the addition of a subsystem. All you need
is to add to either the database entry (when back-ldap is a database) or
to the overlay entry (when back-ldap is wrapped by one of the many
overlays built on top of it) a couple of entries that play the role of
roots of the connections and operations entries. The creation of these
entries can be deferred if the parent entries do not exist yet. The one
related to connections can take care of creating volatile children. The
ones related to operations can have specific callbacks, and the parent
entry can have a callback that creates the children when they do not exist
yet. I'm trying to work out a fix for it.
p.
p.
3:31 a.m.
New subject: (ITS#7182) back-ldap monitoring improvements
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 04/09/2012 03:46 PM, masarati(a)aero.polimi.it wrote:
> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
>
> On 04/04/2012 03:26 PM, hyc(a)symas.com wrote:
>> See ITS#7225.
>>
>> Even after the SEGV is patched, the pcache slapd fails to start
>> in test020 because the monitor calls are unable to register
>> their entries. Something is wrong in your initialization code.
>
> When the ldap database is opened before the monitor, all
> registration is deferred and fake OK status is returned. Then,
> while the subsystems are initializing, the new subsystems (that
> have to derive their DN from something) do not yet have access to
> the DN of the database monitor entry (even though it may already
> exist). Only after all subsystems have been opened does the
> deferred database registration proceed, but by then there is no
> way to notify anyone that the DN has been published. Thus we are
> left with a chicken-and-egg problem.
>
> One way out of this I currently see is providing a
> register_database callback that is called immediately when no
> deferring takes place or immediately after the entry in
> limbo_queue has been processed. This way once the DN information
> is ready, the subsystem registration can start safely.
>
> There is an alternative, adding a defferable monitor_subsys
> registration (and alimbo entry type) that, if monitor is not
> opened, takes place in the second phase (roughly at the same time
> as above).
>
> There are aspects in which either one is cleaner, whereas the
> other one can backfire/clutter the API and vice versa for others.
> I have not decided yet.
I think the problem (and the patch) can be greatly simplified and
made clearer by totally eliminating the addition of a subsystem.
All you need is to add to either the database entry (when back-ldap
is a database) or to the overlay entry (when back-ldap is wrapped
by one of the many overlays built on top of it) a couple of entries
that play the role of roots of the connections and operations
entries. The creation of these entries can be deferred if the
parent entries do not exist yet. The one related to connections
can take care of creating volatile children. The ones related to
operations can have specific callbacks, and the parent entry can
have a callback that creates the children when they do not exist
yet. I'm trying to work out a fix for it.
p.
I have uploaded a patch to this to
ftp://ftp.openldap.org/incoming/Ondrej-Kuznik-20120412-ITS%237225.tgz
The first patch adds the monitor_subsys_register_late that, if monitor
is not opened yet, queues up a limbo entry instead of registering the
subsystem right away.
The others perform some code cleanup. Feel free to (not) include any
part you want.
The attached file is derived from OpenLDAP Software. All of the
modifications to OpenLDAP Software represented in the following
patch(es) were developed by Acision. Acision has not assigned rights
and/or interest in this work to any party. I, Ondrej Kuznik am
authorized by Acision, my employer, to release this work under the
following terms.
The attached modifications to OpenLDAP Software are subject to the
following notice:
Copyright 2012 Acision
Redistribution and use in source and binary forms, with or without
modification, are permitted only as authorized by the OpenLDAP Public
License.
- --
Ondrej Kuznik
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk+GrvMACgkQ9GWxeeH+cXsurwCcDiYWJHp0auIFNrhNSEP+Sig+
G7AAn09FUw0Rx8yB2VXy8dqraO4VlsSM
=II+c
-----END PGP SIGNATURE-----
This e-mail and any attachment is for authorised use by the intended recipient(s) only. It
may contain proprietary material, confidential information and/or be subject to legal
privilege. It should not be copied, disclosed to, retained or used by, any other party. If
you are not an intended recipient then please promptly delete this e-mail and any
attachment and all copies and inform the sender. Thank you for understanding.
4063
days inactive
4070
days old
2 comments
2 participants
participants (2)
-
masaratiļ¼ aero.polimi.it -
Ondrej Kuznik