-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hi, while in progress of adding further monitoring capabilities to the back-ldap backend I stumbled over a weirdness in how the monitor handles the COMPARE operation: If a compare request is issued, the entry is retrieved directly from the monitor cache, triggering no updates, thus the outcome of that comparison is based on outdated or default information (depends on when an update was last triggered).
As a minimum example, having a fresh instance of cn=monitor (that you have not searched since startup) compare the monitoredInfo attribute of cn=Uptime,cn=Time,cn=monitor to "0", you should get LDAP_COMPARE_TRUE.
I've been forced to make a small change to the back-monitor subsystem API locally (will upload the patch shortly), so I could fix this too now that I've become familiar with the code a bit.
- -- Ondrej Kuznik
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.
Ondrej Kuznik wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hi, while in progress of adding further monitoring capabilities to the back-ldap backend I stumbled over a weirdness in how the monitor handles the COMPARE operation: If a compare request is issued, the entry is retrieved directly from the monitor cache, triggering no updates, thus the outcome of that comparison is based on outdated or default information (depends on when an update was last triggered).
As a minimum example, having a fresh instance of cn=monitor (that you have not searched since startup) compare the monitoredInfo attribute of cn=Uptime,cn=Time,cn=monitor to "0", you should get LDAP_COMPARE_TRUE.
I've been forced to make a small change to the back-monitor subsystem API locally (will upload the patch shortly), so I could fix this too now that I've become familiar with the code a bit.
Sounds good, just submit the patch to ITS...