I have few enhancements that could go into 2.4 based on consensus.
- BDB_MONITOR_IDX: monitor missing indices in searches. Let me remember that this feature allows to monitor (thru cn=Monitor) how many search candidate selections missed an index, and what index type. It costs a mutex lock/unlock for each call to bdb_index_param().
- pcache private database access: add a control and an exop that allow access to the private database for administrative/monitoring purposes, and consistent cached query removal (namely: removal of a specific query and related queryID from participating entries; removal of an entry and invalidation of all related queries, ...)
Please comment.
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: pierangelo.masarati@sys-net.it ---------------------------------------
Pierangelo Masarati wrote:
I have few enhancements that could go into 2.4 based on consensus.
- BDB_MONITOR_IDX: monitor missing indices in searches. Let me remember
that this feature allows to monitor (thru cn=Monitor) how many search candidate selections missed an index, and what index type. It costs a mutex lock/unlock for each call to bdb_index_param().
Why the mutex? The count doesn't need to be accurate. I would just let it go unprotected, the real point is zero vs non-zero, the magnitude will be close enough to correct in most cases.
- pcache private database access: add a control and an exop that allow
access to the private database for administrative/monitoring purposes, and consistent cached query removal (namely: removal of a specific query and related queryID from participating entries; removal of an entry and invalidation of all related queries, ...)
I don't see any reason not to. Have you got a spec for the control and exop?
Please comment.
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: pierangelo.masarati@sys-net.it
Howard Chu wrote:
Pierangelo Masarati wrote:
I have few enhancements that could go into 2.4 based on consensus.
- BDB_MONITOR_IDX: monitor missing indices in searches. Let me remember
that this feature allows to monitor (thru cn=Monitor) how many search candidate selections missed an index, and what index type. It costs a mutex lock/unlock for each call to bdb_index_param().
Why the mutex? The count doesn't need to be accurate. I would just let it go unprotected, the real point is zero vs non-zero, the magnitude will be close enough to correct in most cases.
Not worried by being accurate, but by potential indetermination of concurrently performing algebra on non-atomic types (no idea of how this could surface, though: one count missing?, sigsegv? death by chocolate?).
- pcache private database access: add a control and an exop that allow
access to the private database for administrative/monitoring purposes, and consistent cached query removal (namely: removal of a specific query and related queryID from participating entries; removal of an entry and invalidation of all related queries, ...)
I don't see any reason not to. Have you got a spec for the control and exop?
Maybe not really a spec... http://www.openldap.org/faq/data/cache/1420.html.
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: pierangelo.masarati@sys-net.it ---------------------------------------
Pierangelo Masarati wrote:
Not worried by being accurate, but by potential indetermination of concurrently performing algebra on non-atomic types (no idea of how this could surface, though: one count missing?, sigsegv? death by chocolate?).
Ah I see, you're inserting records into an AVL tree. OK, since it's only going to occur for non-indexed searches, the current code looks fine.
- pcache private database access: add a control and an exop that allow
access to the private database for administrative/monitoring purposes, and consistent cached query removal (namely: removal of a specific query and related queryID from participating entries; removal of an entry and invalidation of all related queries, ...)
I don't see any reason not to. Have you got a spec for the control and exop?
Maybe not really a spec... http://www.openldap.org/faq/data/cache/1420.html.
-
Howard Chu -
Pierangelo Masarati