> Looking at openldap 2.4.23, it seems that Server Side Sorting is now > supported - is this documented somewhere? <http://www.openldap.org/software/man.cgi?query=slapo-sssvlv&apropos=0... --Quanah

and because op->ors_slimit is now 0 instead of SLAP_NO_LIMIT (-1). Any ideas?

When using the sssvlv overlay how does the client tell the server that the

I have multiple ldap servers using replication: one provider and multiple consumers. In my multiple consumers' slapd.conf, the replication rid is the same: syncrepl rid=123. I wonder if this is a problem. Should the rid for each consumer be unique? why?

>>> When using the sssvlv overlay how does the client tell the server that the >> sort request can be thrown away, so that sort requests don't hang around until >> sssvlv-max or sssvlv-maxpercon are exceeded? >> >> There is no official mechanism for this. This is a flaw in the Sorting/VLV >> specification. For Paged Results you simply send a followup request with >> pagesize set to zero, but that doesn't apply for VLV. >> >> I believe in our current implementation, if you send a new Paged Results >> request on a connection that has VLVs outstanding, one of the VLVs will be >> aborted. Unfortunately, if you have multiple VLVs outstanding, there's no way >> to determine which one gets aborted. (Apparently this was overlooked when >> patching the overlay to allow multiple VLVs on a connection...) > > Thanks for the info. > Is it the case that sort requests are associated with a particular connection? What does RFC2891 say?

>> From my testing it seems that a sort request will remain active in the server evenif the client disconnects, which doesn't seem right. How are you determining that this is the case?

>>>> When using the sssvlv overlay how does the client tell the server that the >>> sort request can be thrown away, so that sort requests don't hang around until >>> sssvlv-max or sssvlv-maxpercon are exceeded? >>> >>> There is no official mechanism for this. This is a flaw in the Sorting/VLV >>> specification. For Paged Results you simply send a followup request with >>> pagesize set to zero, but that doesn't apply for VLV. >>> >>> I believe in our current implementation, if you send a new Paged Results >>> request on a connection that has VLVs outstanding, one of the VLVs will be >>> aborted. Unfortunately, if you have multiple VLVs outstanding, there's no way >>> to determine which one gets aborted. (Apparently this was overlooked when >>> patching the overlay to allow multiple VLVs on a connection...) >> >> Thanks for the info. >> Is it the case that sort requests are associated with a particular connection? > > What does RFC2891 say? > As far as I can see it doesn't mention connections.

However, looking at the code in sssvlv.c, it appears that a sort operation is associated with a session, and a session is associated with a connection, e.g. on line 900 of sssvlv.c in sssvlv_op_search(): sort_conns[op->o_conn->c_conn_idx][sess_id] = so;

>>> From my testing it seems that a sort request will remain active in the server evenif the client disconnects, which doesn't seem right. > > How are you determining that this is the case? I'm using ldapsearch to test requests with sss and vlv controls. After running several such ldapsearch commands I get an error from the server : # search result search: 2 result: 51 Server is busy text: Other sort requests already in progress I am assuming that the connection to the server is dropped when the ldapsearch command terminates; that must certainly be the case at the client end since the process no longer exists.

> >>> Thanks for the info. > >>> Is it the case that sort requests are associated with a particular connection? > >> > >> What does RFC2891 say? > >> > > As far as I can see it doesn't mention connections. > > Then probably the answer is no. > > > However, looking at the code in sssvlv.c, it appears that a sort operation is associated with a session, and a session > > is associated with a connection, e.g. on line 900 of sssvlv.c in sssvlv_op_search(): > > > > sort_conns[op->o_conn->c_conn_idx][sess_id] = so; > > That's actually limiting VLV requests. You didn't ask about VLV requests, you > asked about sort requests. Ask the wrong question, get a useless answer. So > now, what does draft-ietf-ldapv3-vlv say? > I guess this is a relevant section (the only occurrences of "connection" in the spec): "contextID values have no validity outside the connection and query with which they were received. A client MUST NOT submit a contextID which it received from a different connection, a different query, or a different server." which does partly answer my question about the VLV request, but says nothing about any related sort operation. > >>>> From my testing it seems that a sort request will remain active in the server evenif the client disconnects, which doesn't seem right. > >> > >> How are you determining that this is the case? > > > > I'm using ldapsearch to test requests with sss and vlv controls. After running several such ldapsearch commands I get an > > error from the server : > > > > # search result > > search: 2 > > result: 51 Server is busy > > text: Other sort requests already in progress > > > > I am assuming that the connection to the server is dropped when the ldapsearch command terminates; that > > must certainly be the case at the client end since the process no longer exists. > > I see no such error here. I can run ldapsearch and send VLV requests ad > nauseam. Most likely you have misconfigured something again. Always possible, but I would expect that ldapsearch terminating would cause the server to drop the connection and clean up any sort request associated with a vlv request on that connection. I'll do some more investigation.