> >>> 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
