Norval Hope wrote:
Hi Guys,
There are vicious issues, though. Some of them are related to the way we
have designed the server. For instance, when comparing the previous
searchRequest with the current one, you have to compare attributes, DN and
filters. That's not complicated, except that those elements might not be
equals, just because they have not yet been normalized at this point (in
SearchHandler).
I'm missing something here - why is comparing search results required?
We have to compare the SearchRequest, not the SearchResult. This is
dictated by the RFC, and it makes sense, as if you change the filter,
the baseDN or something else, then it's another request.
I would have thought that all that would be stored on the server-side
for the paged search would be a key that could be used to look up a
live cursor, in which case there would never be a need to compare
search result entries (just to call Cursor.next() N times until a full
page of results could be returned, and when the next request came to
use the key stored in the session to look up the cursor and repeat).
This is a big issue. At this point, we can manage to normalize the DN and
attributes, but for the filter, this is another story. This make me think
that the Normalize interceptor is not necessary, and that it should be moved
up in the stack (in the codec, in fact).
>From the perspective (in part influenced by my VD work, but also
driven by encapsulation considerations) I think things are cleaner
when the codec (or at least some well defined layer of the codec) does
*only* the coding and decoding job, without any expectation of
normalization or access to schema information. IMO for the VD usecase
the AD server shouldn't expect schema information to be available, as
the "real" validation is going to be performed on the ultimate
concrete endpoints and the AD server is just acting as a transport /
container.
maybe, but from the server POV, this is really a problem. Right now, we
already do a DN normalization because we need it to manage referrals
before the request goes through the interceptor chain.
We discussed a lot about VD architectures with Alex, and my personal
vision is that it's almost impossible to manage correctly a VD without
having a complete schema knowledge of all the targeted servers. But
until I implement a VD myself, and face all the associated problems, I
may miss something.
Otherwise, the other problem we have is the Cursor closure. When we are done
with them, we should close those guys. This is easy if the client behave
correctly (ie, send a last request with 0 as the number of element to
return, or if we reach the end of the entries to return), but io the client
don't do that, we will end with potentially thousands of open cursors in
memory.
So we need to add a cleanup thread associated with each session, closing the
cursor after a timeout has occured.
I'd expect a single thread (or singleton execution Executor) could do
this job for all sessions.
Yep, this is the base idea.
And also if the searches are being paged
I'd imagine retrieving a single page of search results could also be
done in the MINA / AD worker thread rather then requiring a separate
thread, unless the Cursor implementation itself mandates a specific
thread is kept around.
No, the way it works is simple: we use the request's thread to handle
the cursor. Currently, I'm storing the cursor into the session, and
restore it when a new paged request arrives. It works pretty well. I
have not yet committed the ocde, because I have some issues with size
limit management, but I'm almost done (and I was busy those last few
days too ...)
Hence the only resources needed for each search
request would be an entry in a <String, Cursor> hashmap (presuming the
key stored is a string) and the Cursor itself.
The couple I store in the session is <cookie, pagedSearchCookie> where
the pagedSearchCookie object contains all the needed information to
manage the paged search and the current cursor.
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org
