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