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.
More investigation done, and the problem appears to be another difference between specifying the sssvlv overlay as global or local to the database config.
If I specify the sssvlv overlay in the database config then I can also send VLV requests ad nauseam, I only see the error when I specify the sssvlv overlay as global.
Chris