directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Karasulu <akaras...@apache.org>
Subject Re: [index] OneLevelIndex removal
Date Fri, 13 Apr 2012 06:52:20 GMT
On Thu, Apr 12, 2012 at 7:00 PM, Selcuk AYA <ayaselcuk@gmail.com> wrote:

> On Thu, Apr 12, 2012 at 7:14 AM, Alex Karasulu <akarasulu@apache.org>
> wrote:
> >
> >
> > On Thu, Apr 12, 2012 at 4:35 PM, Emmanuel Lécharny <elecharny@gmail.com>
> > wrote:
> >>
> >> 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<elecharny@gmail.com>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.
>
> For the server side, I would suggest policing this with a test. When
> cursors open, they can bump a global counter atomically. When they
> close, they can decrement it. We can have a test such that after a
> bunch of operations, this counter at the server side should be zero.
>
>
Great idea!

-- 
Best Regards,
-- Alex

Mime
View raw message