RE: sssvlv
>>> 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.
Chris