[Issue 10229] New: ldap_result, when invoked with MSG_RECEIVED and a timeout value set to 0 (polling), does not return all available messages until it is called again
https://bugs.openldap.org/show_bug.cgi?id=10229
Issue ID: 10229 Summary: ldap_result, when invoked with MSG_RECEIVED and a timeout value set to 0 (polling), does not return all available messages until it is called again Product: OpenLDAP Version: 2.6.8 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: libraries Assignee: bugs@openldap.org Reporter: nivanova@symas.com Target Milestone: ---
The issue is noticeable when ldap_result is used by the proxy back-ends. It has not affected back-meta behavior, because when a first call is unsuccessful, it retries with a small timeout. back-asyncmeta will also usually call it twice on the same connection from different threads, although this is not a desired behavior.
https://bugs.openldap.org/show_bug.cgi?id=10229
--- Comment #1 from Ondřej Kuzník ondra@mistotebe.net --- Does ITS#10060 (not in 2.6 though) relate to this in any way?
https://bugs.openldap.org/show_bug.cgi?id=10229
--- Comment #2 from Nadezhda Ivanova nivanova@symas.com --- (In reply to Ondřej Kuzník from comment #1)
Does ITS#10060 (not in 2.6 though) relate to this in any way?
Doesn't seem so at the moment, it is in the same code, but this problem occurs when all=2 (MSG_RECEIVED) with a tv={0} (polling). Any other combination of these and things work as expected.
https://bugs.openldap.org/show_bug.cgi?id=10229
--- Comment #3 from Ondřej Kuzník ondra@mistotebe.net --- Could you describe the issue in more detail? i.e. what does it mean "unsuccessful" in your description, does it mean it will return an error? What error?
https://bugs.openldap.org/show_bug.cgi?id=10229
--- Comment #4 from Nadezhda Ivanova nivanova@symas.com --- Even though there is still at least one message in ld_responses, it sets errno to -5 (timeout), instead of returning this message in the *result pointer, as should be the case when called with MSG_RECEIVED.
https://bugs.openldap.org/show_bug.cgi?id=10229
Quanah Gibson-Mount quanah@openldap.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords|needs_review | Target Milestone|--- |2.6.9
https://bugs.openldap.org/show_bug.cgi?id=10229
Ondřej Kuzník ondra@mistotebe.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |IN_PROGRESS Ever confirmed|0 |1
--- Comment #5 from Ondřej Kuzník ondra@mistotebe.net --- A patch is available at https://git.openldap.org/openldap/openldap/-/merge_requests/722
It keeps the current behaviour of MSG_RECEIVED that if there are matching messages in ld_responses, the stored messages are returned and there is no attempt to read from a socket in that case. The caller was going to call it again anyway.
https://bugs.openldap.org/show_bug.cgi?id=10229
Quanah Gibson-Mount quanah@openldap.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Target Milestone|2.6.9 |2.6.10
https://bugs.openldap.org/show_bug.cgi?id=10229
--- Comment #6 from Nadezhda Ivanova nivanova@symas.com --- This patch has been manually tested to the best of our ability, but we were planning to eventually implement an automatic test that guarantees that there are multiple msgids in the chain to retrieve with a single ldap_result call. Asyncmeta was adjusted to not use MSG_RECEIVED without any noticeable performance issues, and since writing such a test was not trivial, we postponed it. At this point there is no code in OpenLDAP that uses this particular scenario, and to the best of our knowledge, the patch works and is safe. It may be a good idea to implement the test when we decide to merge it in an official release.
-
openldap-its＠openldap.org