directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Karasulu <>
Subject Re: [index] OneLevelIndex removal
Date Wed, 11 Apr 2012 20:38:16 GMT
On Wed, Apr 11, 2012 at 4:04 PM, Emmanuel L├ęcharny <>wrote:

> Hi guys !
> so I completely removed the OneLevelIndex from the server. The branch
> (index) has been successfully merged back into trunk, and I will now work
> on removing the SublevelIndex from the index branch.
> In the process, I spent 3 days closing all the cursors that weren't closed
> after having been used. This was *BORING*. In the future, I would really
> appreciate if those who use the cursors double check that they have closed
> them.
> To do that, I added some logs in every cursor constructor and every
> close() method, and matched the opens with the closes. Do'nt ask me if this
> was fun to match them... I created a small program which was able to do
> that for me, but this is not enough to know that a cursor has been created
> but not closed, we also have to know where it has been created.
> 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?

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.

> The pb is that it gives no clue about where those cursors have been
> created, unless we associate a stackTrace to this information. Really not
> possible in production, but we might add an extended request to activate
> this mode, or a flag in the config.
> If anyone has a better idea ?
An aspect oriented solution might work well here.

> Thanks !
> --
> Regards,
> Cordialement,
> Emmanuel L├ęcharny

Best Regards,
-- Alex

View raw message