[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: use of server-side sorting and virtual list view controlsblocks slapd
"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
--
Dieter Klünter | Systemberatung
sip: +49.40.20932173
http://www.dpunkt.de/buecher/2104.html
GPG Key ID:8EF7B6C6