directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel Lécharny <>
Subject Re: [index] OneLevelIndex removal
Date Thu, 12 Apr 2012 13:35:33 GMT
Forgot to reply to this mail, which raises interesting points.

More inside.

Le 4/11/12 10:38 PM, Alex Karasulu a écrit :
> On Wed, Apr 11, 2012 at 4:04 PM, Emmanuel Lécharny<>wrote:
>> I think we should add some mechanism in the server to check that
>> automatically, to avoid doing it by hand (there are hundreds of tests to
>> check...). One solution would be to keep a track of every cursor
>> construction in a HashMap, and to remove them when the cursor is closed.
>> The remaining cursors are likely not closed.
> It would be nice to have a Cursor monitor that every opened Cursor
> registers with but this needs to happen automatically. Then when out of the
> creation scope the Cursor is expected to be closed and if not this is
> handled automatically. However does creation scope work well since
> sometimes we create Cursors and pass them up?
We do have a monitor, which is currently used to check that the cursor 
is not closed when we try to use it. We certainly can use this monitor 
for more than just checking such thing.

Now, the pb is that the scope is not as easy to determinate than for a 
variable in Java. For instance, if we consider persistent searches, or 
paged searches, or even an abandonned search request, the scope is 
pretty wide...

Though we can have a set of rules that help us to close the cursor 
automatically :
- if we get an exception during a SearchRequest, then the cursors must 
be closed immediately. As soon as we store the cursors into the 
SearchContext, this is pretty easy to do
- an AbandonRequest will close the cursor automatically too (getting the 
cursor from the abandonned request)
- when we process the SearchResultDone, we can also close the cursor for 
the current search request (this work for PagedSearch too)
- for pagedSearch, if the user reset the search by sending 0 as the 
expected number of entries to return, then the cursor will be freed
- for persistent searches, as it will be closed by an unbind or an 
abandon request, we are fine
- when a client unbinds, then all the pending cursors will be closed.

All in all, we have everything needed to close the cursors 
automatically, assuming we keep all the cursors into the session.

On the client side, this is another issue... As cursors are created by 
the client code, we have no easy way to determinate when we should close 
the cursors, except when the connection is closed or an abandon 
request/unbind request is sent. Of course, when the server returns a 
searchResultDone we could also close the cursor. Remains the situations 
where the client has fetched some entries (but not all), and haven't 
unbind nor abandonned the search.

In any case, this is less critical as we don't have to deal with the txn 
layer. The client will just blow away with some nasty OOM sooner or 
later... but this is not worse than what we get with NamingEnumeration 
in JNDI, nah ?

Have I covered all the server options ? Or did I miss something ?
> This sounds like something that can be handled nicely using an aspect
> oriented solution. Now these things are heavy if you use AspectJ or
> something like that but other simpler solutions exist to bytecode splice
> compiled code to automatically handle these things. Maybe our past
> experiences with Aspects might make us reconsider.
A bit overkilling, IMO?

Thanks !

Emmanuel Lécharny

View raw message