Hello Dieter! I got the error "serverSort control: No ordering rule" before I altered the LDAP schema adding an ordering rule:
attributetype ( OCSP-R-LDAP-attributetype:10 NAME 'SNcertNr' DESC 'secunet OCSP-R-LDAP-attributetype:10' EQUALITY caseIgnoreMatch ORDERING caseIgnoreOrderingMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE )
After receiving 10 entries on client side I press "enter" but after that the client immediately outputs the "sizelimit exceeded stuff".
It doesn't matter if I mark the extensions as critical or not: the effect remains the same ("sizelimit exceeded").
Regards, Hartmut
-----Ursprüngliche Nachricht----- Von: openldap-technical-bounces+hartmut.lehnert=secunet.com@OpenLDAP.org [mailto:openldap-technical-bounces+hartmut.lehnert=secunet.com@OpenLDAP.org] Im Auftrag von Dieter Kluenter Gesendet: Mittwoch, 26. Mai 2010 18:37 An: openldap-technical@openldap.org Betreff: Re: use of server-side sorting and virtual list view controlsblocksslapd
"Lehnert, Hartmut" Hartmut.Lehnert@secunet.com writes:
Hi Dieter!
I use the search command
/home/openldap/openldap-2.4.21-install/bin/ldapsearch -h localhost -p 9389 -D cn=openldapadmin -w welcome -b o=CustomerCA,c=de -s sub -E!sss="sncertnr" -E!vlv="0/9/0/1:objectclass=SN-ISIS-MTT-MainCert" sncertnr
I just wonder that you don't get an error, something like: result: 18 Inappropriate matching text: serverSort control: No ordering rule because you don't provide an ordering rule for sncertnr
On client side this looks like as follows:
# extended LDIF # # LDAPv3 # base <o=CustomerCA,c=de> with scope subtree # filter: (objectclass=*) # requesting: sncertnr # with server side sorting critical control # with virtual list view critical control: 0/9/0/1 #
# R\C3\BCger OttoSER:9000, testsuite, CustomerCA, de dn:: Y249UsO8Z2VyIE90dG9TRVI6OTAwMCxvdT10ZXN0c3VpdGUsbz1DdXN0b21lckNBLGM9ZGU= SNcertNr: 9000
[SNcertNr: from 9001 to 9008]
# R\C3\BCger OttoSER:9009, testsuite, CustomerCA, de dn:: Y249UsO8Z2VyIE90dG9TRVI6OTAwOSxvdT10ZXN0c3VpdGUsbz1DdXN0b21lckNBLGM9ZGU= SNcertNr: 9009
# search result search: 2 result: 0 Success control: 1.2.840.113556.1.4.474 false MAMKAQA= sortResult: (0) Success control: 2.16.840.1.113730.3.4.10 false MA8CAQACAQwCAQAEBBD9LAg= vlvResult: pos=0 count=12 context=EP0sCA== (0) Success # numResponses: 11 # numEntries: 10 Press [before/after(/offset/count|:value)] Enter for the next window.
According to your virtual view values you require 9 entries, out of 12 and you recieved 10 Did you press Return in oder to present the next entries out of a total of 12?
# extended LDIF # # LDAPv3 # base <o=CustomerCA,c=de> with scope subtree # filter: (objectclass=*) # requesting: sncertnr # with server side sorting critical control # with virtual list view critical control: 0/9/9/12 #
# search result search: 3 result: 4 Size limit exceeded
# numResponses: 1
It seems you have started a new search without interrupting the previous search.
Debug output of the slapd server that concerns to this request:
daemon: activity on 1 descriptor daemon: activity on: slap_listener_activate(7):
slap_listener(ldap://0.0.0.0:9389/)
daemon: listen=7, new connection on 11 daemon: added 11r (active) listener=(nil) conn=1000 fd=11 ACCEPT from IP=127.0.0.1:44124 (IP=0.0.0.0:9389)
[...]
conn=1000 op=1 SEARCH RESULT tag=101 err=0 nentries=10 text=
For connection 10 entries were found
[...]
ber_get_next on fd 11 failed errno=0 (Success) connection_read(11): input error=-2 id=1000, closing. connection_closing: readying conn=1000 sd=11 for close connection_close: deferring conn=1000 sd=11 conn=1000 op=3 do_unbind conn=1000 op=3 UNBIND connection_resched: attempting closing conn=1000 sd=11 connection_close: conn=1000 sd=11 daemon: removing 11 conn=1000 fd=11 closed daemon: epoll: listen=7 active_threads=0 tvp=NULL
Here connection 1000 got unbind and the connection has been closed, and 0 active threads.
Sending the search request again blocks the server; see output on client side:
# extended LDIF # # LDAPv3 # base <o=CustomerCA,c=de> with scope subtree # filter: (objectclass=*) # requesting: sncertnr # with server side sorting critical control # with virtual list view critical control: 0/9/0/1 #
# search result search: 2 result: 51 Server is busy text: Other sort requests already in progress
The corresponding server debug output looks like this:
daemon: activity on 1 descriptor daemon: activity on: slap_listener_activate(7):
slap_listener(ldap://0.0.0.0:9389/)
daemon: listen=7, new connection on 11 daemon: added 11r (active) listener=(nil) conn=1001 fd=11 ACCEPT from IP=127.0.0.1:37542 (IP=0.0.0.0:9389)
[...]
conn=1001 op=0 BIND dn="cn=openldapadmin" method=128 do_bind: version=3 dn="cn=openldapadmin" method=128 ==> bdb_bind: dn: cn=openldapadmin conn=1001 op=0 BIND dn="cn=openldapadmin" mech=SIMPLE ssf=0 do_bind: v3 bind: "cn=openldapadmin" to "cn=openldapadmin" send_ldap_result: conn=1001 op=0 p=3 send_ldap_result: err=0 matched="" text="" send_ldap_response: msgid=1 tag=97 err=0
[...]
=> get_ctrls: oid="2.16.840.1.113730.3.4.9" (critical) ber_scanf fmt ({ii) ber:
[...]
conn=1001 op=1 SEARCH RESULT tag=101 err=51 nentries=0 text=Other sort requests already in progress
ldap_read: want=8 error=Resource temporarily unavailable conn=1001 op=2 do_unbind conn=1001 op=2 UNBIND connection_closing: readying conn=1001 sd=11 for close connection_resched: attempting closing conn=1001 sd=11 connection_close: conn=1001 sd=11 daemon: removing 11 conn=1001 fd=11 closed
I must admit I have no clue, and I cannot reproduce, neither on openldap-2.4.21 nor on openldap HEAD.
Could you please try without criticallity? that is without exclamation mark (!).
-Dieter